April 2003 - Rabbit@DeathsDoor.com Teacher's Guide for teaching Wire Phreaking 101. COURSE: WP101; Taught by a Rabbit or your local guide. A 3 week (9 session) academic course on technology, implications, and ethics of design insecurity. -Rabbit Rabbit@DeathsDoor.com Table of Contents: (Included documentation) Introduction Syllabus (an overview of WP101) WEEK ONE Intro WEEK TWO Intro WEEK THREE Intro Teacher and Course Supplements, Schedules, etc. ---PGBRK Introduction: In the balance between the intellectual sector and realms of suppression, there is a doctrine of ethical engagement and discourse; typically, a competent individual will present findings of an intellectual nature, especially in regard to flaws in a product, to the corporation or entity charged with its management. It is expected, especially when the flaw is a critical security issue on a system which manages hundreds of billions of dollars of intellectuals' assets, that the corporation or entity would proactively participate in compensating for its errors, announcing its flaws to all interested or impacted parties, and thus prevent any exploitation of said flaw. In the case of Blackboard, Inc., whose products control all logistic, financial, and security infrastructure at a large majority of academic institutions (as well as corporate, federal, and related facilities), a forceful cover-up and illegally false representation of the integrity of their product by this operation directly compromises the security, integrity, and logistic elements of ALL parties associated to a client implementation or installation of their product. This course is intended as a clarification and discussion-inducing session which will enlighten interested parties to the theory and ease of compromise or exploitation of a plethora of technologies, and help to elucidate the implications of an illegitimate operation such as Blackboard, Inc. This is in no way an analysis of Blackboard, Inc. or their product offerings. Blackboard, Inc. is referenced due to current ethical conflicts generated by their illegitimate and irresponsible behavior. All topics discussed within this course are intended for theoretical or lab (simulated) settings -- it is highly ill-advised to attempt a real-world implementation, and discouraged by this party -- in order to allow the students to realize the ramifications of technological exploit, especially when such have extreme implications on vast sectors. This course will concentrate on the discussion of findings throughout, especially on the ethical and security ramifications of various technologies. Further information is available via email request to "Rabbit@DeathsDoor.com". ---PGBRK [BEGIN SYLLABUS] Syllabus for Wire Phreaking 101 - WP101: by Rabbit@DeathsDoor.com WEEK ONE: Class 1: Theoretical Discussion of basic wire communications protocol, Design of a physical device suitable for interfacing a computational device to a simulated exploit target, and a general overview of ethical considerations therefore. Class 2: Construction of custom device, optimization of software design, and Lab simulation of physical compromise and system exploitation. Here you will attempt a comprehensive exploitation of your research target - Proof of Concept. Class 3: Final simulation of optimized exploit technology, statement of findings, and comprehensive discussion of findings, as well as discussion of ethical ramifications of development and use. WEEK TWO: Class 1: Conceptual review of system enhancements, including 'attack' techniques, understanding of technological requirement for software/control system design, and circuit optimization for the interface device. Class 2: Test implementation of physical isolation technique, experimentation on methods of transparency, and comprehensive simulation of compromised systems. "Reverse Engineering" and Proof of Operation. Class 3: Final optimization tests for artificial core technology (esp. software), statement of findings, and discussion of technological characteristics of the target, especially protocol and methods. This discussion will concentrate on improvements to the *target's* design, and briefly discuss conceptual issues for the use of an artificial core. WEEK THREE: Class 1: This week will be dedicated to a comprehensive understanding of the ramifications for using such an easily compromised device. This discussion will concentrate on the ability to spoof any element of the system based entirely on an automated analysis of the target, and a discussion of the logistic and security implications of such ineffective systems. Class 2: This Lab session will concentrate on the comprehensive mapping of all known devices of target interest, and also introduce security complications for the 'attack' like unexpected control codes, inquiries, or administrative overrides, as well as other line activity which was not previously encountered by the artificial devices. Class 3: Having gained a comprehensive understanding of the target system, and thoroughly reviewed the operation and compromise of all related technological components, it is only expected that we now apply this understanding to the enhancement of implementations of this system. Depending on your site and logistic predicament, you may be given the opportunity by site administration to tour a high-security implementation of your target system. If possible, it would be desirable to fully understand the ease of compromise of a building or structure, information system, or critical area, entirely based on your lab analysis of these systems. The primary goal, either through a physical tour or a conceptual diagram of implementations, is to assist the administrative party in enhancing their system implementation to harden the ease of exploit or compromise. ----- This will signify the end of the Wire Phreaking 101 course, however the Wire Phreaking 102 course will assume these prerequisites as well as cover advanced target analysis, interface system design, and design and application of completely automated systems to perform these tasks. Wire Phreaking 103 - "Applications", is a comprehensive course in physical and technological assault and compromise, typically intended for security personelle and developers, as well as tactical intelligence and reconnaissance operatives. WP103 expects a strong moral and ethical understanding of the implications of physically compromising high-security facilities, and expects certain security classifications and clearances in order to properly analyse the techniques for doing so. Please feel free to contact Rabbit@DeathsDoor.com for further information. [END SYLLABUS] ---PGBRK Teacher's Manual for teaching Wire Phreaking 101. by Rabbit@DeathsDoor.com, April 2003. WEEK ONE. With the advent of higher speed computational processors on mobile devices, such as wince/palm handhealds, laptop computers, or whatnot, computational approaches to Phreaking are far more efficient than in our last document of the late 1980's. This text, prepared in response to signal hacking forthcomingly rampant on college campuses this April of 2003, will approach the highly simplistic approach to basic line Phreaking easily implemented in an hour lab session, as well as some plausible implementation philosophies to assist the discussion of technology ethics and issues concerning ease of compromise in poorly designed communications systems. Additionally, below the **'s, is a highly feasible scenario for discussion amongst work groups regarding ethical, technological, and logistic theory, highly applicable to this scenario. Cross referencable documentation and searchable phrases would be "Phreaking" "Phrack" "Boxing" "Black Box" "Purple Box" "[other colors] Box", including comprehensive documentation from 1986 to 1993 regarding physical hacking and Phreaking. See the companion list of references. This variation will minimize physical requirements, and make comprehensive use of readily available technologies such as computers. There will be no dependency on any 3rd party product or device aside from basic electrical components. Included in this lecture are variations on the same physical device which provide the only physical requirement for this experimentation for intellectual enlightenment. This introductory technique utilizes a parallel tapping method, we will not discuss the use of inductive pickups or remote modulators. ---PGBRK Historically, prior the transition of landline telephone service to digital routing, and even prior the realization by the phone companies the simplicity of signal reproduction for coin tones, Phreaking was a commonplace activity across this planet. In these ancient times, competence deficient corporations apparently intentionally built exploits into their technology, simply to give sheeple an opportunity to be entertained. In this modern age, remnants of these intellectually stimulating corporate gifts remain active, in a current case, some schoolchild noticed a long known characteristic of card reader systems used at most major universities, and thus ethical concerns related to his findings (and response thereto) stimulate this in-class discussion. The logic is simple, in your Intro to Signals class from 5th grade, you covered binary signals which depend on voltage fluctuations on a timed circuit. Here's your first opportunity to experiment with this working knowledge in the real world. What is a binary signal? it's a waveform. What is a sound? its a waveform. What 2 mini audio jacks are available on most portable computers? Line IN and SPKR OUT? Typically, any 486DX2 laptop through modern devices have at least a 44kHz sampling rate on their sound card, most since 1997 are in excess of x-hundred kHz. Go look up the LINE-IN voltage specs for a typical computer soundcard. Go look up the SPKR-OUT voltage specs for a typical computer soundcard. If your LINEVAL is 1..5 centered at 3v, and your target is a 12 volt, 10 volt and 15 volt, 5 volt, or other related value, you will probably need a resister to normalize the transfer voltage between the exploit line and the voltage handling specs of the computational device. The same applies for your SPKR-OUT values. Typically, one value unit on the sound card directly correlates to a voltage level. Study your target specs: A Phone: 12v (sometimes 5v) line amplitude. A card reader: speced as 10 and 15 volt, parallel lines. Your target may differ, this is a homework/lab project, go do some basic research. So, now, you know the target specs, and you know the specs for the computational system and its interface that you plan to use. The concept "Sampling Rate": A 56kbit analogue modem, such as that connected to your phone line where you got this file from, is 56 thousand cycles per second. The spec for a card reader is 9600 baud, nine thousand six hundred cycles per second. The soundcard samples at MINIMUM 44 thousand cycles per second, preferably in excess of 150kHz for this example. So, you have a computational system, a set of values, and a target. You know the voltage of your target, you know the voltage of your control system. Determine the value of the Resister needed to make your target values compatible with your computational device. Determine the values of the Power Amplifier needed to make your line-out or spkr-out compatible with the target. Write down the specs on these two components on your shopping list. If the amp needs external power, or you wanna make things hard, consider using a DB9 (comm port) or PS2/AT (external keyboard) plug to get a 12 or 5v supply. Notice that the target also has a DC power source. Your device should be self-contained, small, and primitive. (easily built and utilized) Schematic: Target line 1 --- resister --- mini plug --- computer LineIn/mic computer line-out or SPKR (your choice) --- power amplifier --- Target Line 1 If you are lucky and have a laptop with a 20v (hundred watt) speaker out, you get things even easier. If you care about power feedback and the health of the computer, you might want a couple diodes and maybe a capacitor, but not particularly necessary. If your target uses a parallel feed circuit, ensuring data accuracy at slow speeds in harsh environments, sorta like those card readers, you're gonna need two resisters and two amplifiers... Why? cuz the lines are different voltages, cycled and modulating in parallel. TGT1(low) --- --- resister --- plug --- computer TGT2(high) --- R2 -| Obviously R2 is the difference between computer and target2 minus target1..... Do the same coupling for the amps... computer-plug-amp1-{amp2-TGT2, TGT1} So now you have two parallel circuits, matched and balanced. Please realize that TGT1+TGT2 is greater than each element..... You can do basic math, put as much accuracy and regulation into the circuit as you desire. Installation Equipment: Truthfully, I cant really see insulated speaker wire unless im really looking for it. Speaker wire is a conductor, use a fairly heavy gauge if your target is higher voltage, you do the math. perhaps target has wires too, they are shielded, however, if you break them, the system malfunctions, and identifies the breach. Possibly those wires string between units, all over the place. In a good place, remove the shielding of the target leads, connect exploitation wires, possibly some alligator clips might be useful, as well as some electrical tape? Supplies: exploit wires -- ummm... its a wire? gator clips -- easier tools to access target lines... that's the experimenter's problem. On your lab desk everything should be easily accessible. THUS: 1-Lead system Materials per each interface unit (telephone or basic circuit): 1 Resister 1 Power Amplifier 2 mono mini male plugs maybe some tape or even an alligator clip. 2-Lead Materials per each interface unit (RS-parallel): 2 Resisters 2 Power Amplifiers 2 mono(or stereo) mini male plugs Depending on Amplifier requirements, if a power tap can not be acquired from the target line, you may require either a DB9/ps2 male interface plug or other external power source. Maybe some tape, some alligator clips, etc... String the exploit wires somewhere desirable, possibly a nice quite place to stash a laptop, possibly your lab desk, whatever. You now have two (taped leads, so you dont break anything or fry the system when the site employee pulls the wire out of the hiding spot) wires somewhere easily accessible, connected and extending your target system's wires. You have a computer, which just happens to have that software you're about to write on it, as well as a little ball that has two audio plugs sticking out of it, and two alligator clips sticking out the other end. (if targeting a closed circuit such as a telephone, your circuit needs to be closed, an open parallel circuit should be open, obviously, our target is an open circuit. (though 'grounding' might be a significant term)) Remember you are building in parallel to it, in a highly advanced design, they need not physically interact, but the technique for such is highly complex. Your system will physically interface with the target. Look up the phrase "Daisy Chain" ... understand it. Might as well check the protocol expected on the wires, "RS-485" comes to mind today for some reason. If your little ball has a DB9 or PS2 plug, be aware of that too... If it has a second set of gator clips, you know their use. Plug the components of the ball correctly into the well-marked corresponding plugs of the computer. Obviously, now you activate the program, it cycles through the calibration sequence, where it modulates the line and speaker (plug) voltages to a normalized value, guaranteeing that the target voltage is correct... Possibly a multitester would be useful here? clip over to the target leads... You mess that up, you're going to federal prison. Just Joking, you are in a lab setting with a controlled and authorized target! ok, now activate the next stage of the software, its a "Listening mode"... Lookee!!! It's recording line activity! You completed that task in a shorter time period than it took you to read this text. Perhaps there is also a "Talking Mode" in the software as well? OK... Time for the relevant stuff... if you haven't comprehended this thus far, please, go away. Your software is a standard signal analyser, you are polling or recording at a rate faster than the target, you are extrapolating the binary signal which is available on the line. Thresholding? Polling? Fourier? Hundreds of other methods? If you want to sample something like a negotiated 56kbit binary stream, I'd suggest your software sample at 3x that rate, if you want a 9600 baud target.... I really dont care what you do, but perhaps some methods may desync or distort the system, thus identifying the breach... or getting you expelled. NO! this is a LAB setting! Your processor is a P5 or better, your computational capabilities in realtime are SLIGHTLY higher than your target rate... Remember REALTIME. BIDIRECTIONAL. So... you have found some way to record the line-in feed of the computer sound card... nice. WIN32API...? You took this sound data, and somehow thresholded it into a binary signal, with some comprehension of timing and calibration. Neato. What if you want it to talk? You know how fast the baud rate is, even if you had to read it off the wire (this is a 8th grade project, you actually designed something to measure the voltage, adjust the amp and inputs, and then pulled timing data off the wire... automated exploit) Well, the circuit you built already has that capability... SPEAKer... righto. If you cant figure out how to create a sound on that computer, you should have put this down HOURS ago... Note, win32 is distasteful, it has a slight delay in pumping sound output... asm-directsound would be advisable, or a properly calibrated time offset WHICH YOUR SOFTWARE FIGURED OUT during the calibration cycle...... So, binary data, known language, good interface hardware, etc... OK... Now for some theoretical simulation. ISSUES: "DaisyChain"? Voltage drops, signal errors. -- prevent them... "Logistics": Obviously, as stated, this is a LAB experiment where all utilized equipment, targets, and whatnot are CONTROLLED and intended for this purpose. Any attempt to compromise a 3rd party or unauthorized target is HIGHLY ill advised. If the target is a FINANCIAL PROCESSING SYSTEM, then it may be a federal crime to fk with it. I dont control your stupidity. I have absolutely no affiliations with anyone, never have, and never intend to. You get expelled or thrown in federal prison for wire fraud or conspiracy or whatnot, Im gonna laugh at your tail-end. "Compromise": If you distort a signal/system that has been stable for now 20 years, and the controller and system generate errors, it is NOT hard to find the unexpected wire. Fingureprints? There are things such as 'toners' which can easily track rogue wires, including their length and characteristics. See "Logistics"... enough of that. ---PGBRK Theoretical Simulation: Here's a complex analysis for discussion in class, the scenario is simple, and you're gonna watch it happen across the country in the next few months... Let's take the case that your target is a card-debit-authorization-etc type system, such as the one you are interested in and have access to here in the lab setting. As per the speced design of its installation 20 years ago, each chain of components (anything from door locks to money eating machines) is independently connected DIRECTLY to the control system, possibly through mutex or remote interface systems, all of which you are unconcerned with. It is likely that the main controller knows what devices are on each circuit... how else would it talk to them? The basic mode of operation is a simple timing/interrupt system, the core polls all devices to determine their state (door open, room on fire, currently accepting money, dead, etc)... When your card goes through that door opener, it generates a data sequence in the local chips which then wait for a clear cycle (or interrupt the polling cycle) which is then sent down the line in a voltage flux in a basic negotiation and addressing structure. Various hardware versions, devices, etc, may have a different identification technique, etc. This will be determined in the listening cycle. Typically, these are a very basic sequence... "I am DOOR3" "TheHacker" ... Door3 in the main database knows or determines if 'TheHacker' is allowed access, and at what level. I have seen some of these devices go into a WAIT state when there is too much activity on the lines, especially in the laundry room or coke machines, when there are many of them on the circuit. The DOOR is the most primitive, if the device itself opens the door (then do a james-bond hack , break it and touch the wires together, throttle the relay, and decouple the magnet) if it is an independent circuit, the DOOR reader will ask for a go/nogo for 'TheHacker', the response will determine the light. Some of them have a yellow light... They use this to tell the human that its confused (card misread)... Either the controller core or the reader will then trigger a door-open circuit, typically a relay that kills the magnet or door interlock... In the timed version, the control core will accept a read from the swiper, swiper flashes a light, swiper resets. Core tells door to open... Go swipe your card twice, or a good card then a bad card, it still works. (bad card may cause door interlock before you get to it, but...) Door relay has an identity, and typically accepts 3 commands... open, close, and status... polling will generate a single id status report from any and all devices, open commands may or may not return a 'complete'... So, there's a bunch of independently addressed and controlled thingies on a wire. Whoopie. ********* Here's a story for your ethical consideration and discussion: " 'TheHacker' decides that this is such a cool thing -- at least today, late afternoon --, and doesn't care (or is competant enough to not worry about it) about federal, state, local, and institution logistics, including a 10 year prison sentence in a federal penetentariry if someone screws with a money taking/handling system at a public school... So, he says, I've got this thing I stole from the kid who made/used it in class, it seems to work well at signal interfacing. Im a relatively decent coder, so I'm gonna do things right. Scenario: I want to use my school ID card over at the pizza place on main st, or in the caf, bookstore, etc... better yet, one i stole from the same kid i got the plug thing from. Kinda looks like me too... It doesnt have $ on it. Needs at least 20$, right? What do you think? It's a free world, so let's give everyone 20$, that way, its unlikely that someone traces the owner of the card to the ONE ACCOUNT that was hacked, or at least the entire number range around this card... Im assuming that since you're still reading, you aint that dumb, eh? FightClub all the way, baaaahbie! OK, so Im a decent coder, lets get started... We've got a rogue signal coming in as a digital amplitude feed off the soundcard, im sampling at a sufficient rate that I know im not hitting alternate bits, so let's start reading... Im sure that this is a binary system, using a voltage modulating carrier, its coming in at 60-80% volume on the card, so, lets start pulling data... Basic amplitude analysis, OK, I've got the peak thresholds for the voltage (sound amplitude), high and low pass... That was cute, I ran a single pass over the realtime data, took each 'sample' and converted it to a binary signal... I COULD do a double-rate (or higher) sequencing, just to make sure the timing is exact... so lets go at least 4x speed, two guaranteed hits, plus a couple off peak values to get the timing right... Anyways, Pulling data... now we know there's a daisychain of devices on the same line, the core is constantly polling them, and they sometimes talk... Polling... well... what is polling by definition? its a continuous repetition of a cycle, typically with an incrementing value for each device, probably asking for 'STATUS'... Listen for a few hundred cycles, Lookee! Same repeating cycle of commands for status request, PLUS a few interruptions from devices ... ID 5551212 just got a F9 from the vending machine worth .60$ ... ID6669999 just did a 1.50$ transaction at the laundry service (MOST of the schools laundry is controlled with a hardwired relay to the keypad, all it cares is that it gets a 'GO', the remaining value on the account is supplemental data) and has 42.68$ left on the account. That's cute, maybe 6669999 can hook me up with a spin, eh? OK, so we know a vend(value) gets an auth response and a basic data feed with the remaining value... cool, an entire set of devices is now understood. Oh well... this line doesnt have a money-eating device... we kinda need one to figure out how it works... reversing 101... Zen is it? So, we got 666999's 20 loads of wash to exploit... kinda reminds me of all those free payphone calls, yaknow the phone in the lower lounge of the unff dorm is analogue and doesnt have the NewFangled relay that turns off the mouthpiece while dialing... hehe... what was that proggie called... "DTMF Tone Generator" "ToneOut" "RingTones" "PhoneHack" ... and the actual good one from '89 I dont remember the name of right off... Was part of a wardialer suite of programs, came off the renegade bbs I ran long ago... anyways... Ya, that little mini-tape recorder thing... im sure you can find one in the antique shops... So we've gotten a few minutes of intentional data off the line, plus another few minutes reminiscing, and another couple expressing how fking simple this is... OK... there's a money eater down at the commons... tchit... there's cameras all over the area, and i think the controller/relay is in that same office... Isnt there a smaller one that takes 1..20$ bills over in unff dorm... dang, its right next to that payfone!!! Heh, what fun, that kid also lives in unff dorm... whoopie! Door's open, wandering downstairs... people looking at me funnie because im caught up in what looks like a fishing net mess of speaker wire that i didnt bother to coil up when that hot guy (ya, im female) came into the laundry room... hehe OK, there's the target, looks like it's lines run through the laundry room here, to the coke machine (there's a coke machine on the other side of the target as well) and then down to the other laundry at the other end of the hall and the other door reader... Im not gonna tell you which device, or maybe what room the tap is in... its not hard to trace wires, plus there's like 5 dorm rooms, two study halls, and a conference room on the same wall as the target wire... Hmmm... conference room, neutral territory... perfect... complete with a drop ceiling. door's open, pick a tile, crap, chair has rollers, oh well... some ethernet wires, power for the lights, a 1984-era grouping of wires, phone circuits, etc... take a guess... 1984 -- two copper twisted and a 24vdc line? great. TCHIT! the RA... "whatcha doin?" "Phreak you Biiiatch" --- all better. blade... scraping... (i decided not to leave a paper trail at radio shaq, so no gator clips) tie the taps on, drop the line, run it, close the tiles... fall off the chair, on top of the computer of course... gdit... too bad, its not mine anyways, lifted it off that aberchombie chick earlier, dont particularly care, just cracked the screen, nothin bad. danged gloves are hot... anyways continuing. room is cinderblock construction , loft the ratsnest over the wall, neato, janitorial closet WITH a window vent (we're in the partial basement atm -- feel sorrie for the kids living down here, most are CIA/DEA trainees anyways, plus that SS grandfather who supposedly works for that politician's daughter upstairs) ... wires connected, hard to see the data on a rainbow coloured screen, but that's why i wrote the program to autonomously analyse the transactions, map them out, etc... Lookee! 802.11 link on this laptop, lounge within 800 feet... perfect... lets do things right. plug it in, hide it behind the shelf... good thing i coded the proggie with an anti-sleep and remote connect feature, complete remote control, plus a couple ghosting features... back offsite at the house, still got the kid's card, they just left for spring break. The rest are leaving later this weekend, mealies are unavailable because they are are officially on break, cept half the kids still have class/test until two days from now... Warbots, find me a remote relay... double that... lets see the fking feds trace that... ok, connect back in to the host laptop... guess what, hacked relay #3 is an I2 box at a school also on vacation... c0olies... me-remoteServer(.ru)-hacked1-hacked2-hacked3(I2.edu)-Lounge802.11-RainbowTop[-wires-target]... It's been listening for an hour now, slightly after dinner time... good thing its the closest money eater to the only food source on campus open right now ;) Great... 30 positive deposits, 2 balance inquiries, 15 coke machine sales, 12 vends for D6 -- i think that was freetoes (damned pepsico) -- and 3 sets of laundry operations... wash and dry each... deposits... obviously thats our target... two types... a few different sequences... all start with an ID cycle, which returns with the 'yes it exists' and a balance... you have 4 or six buttons, one of these transactions has some funky 'see history' request... looks like a date-value character sequence, plaintext... most of the others are deposits of 1,5,10,20 dollar bills. Transaction here is really simple, everything starts with "valid card?" request, returns ok and current balance, button input, and "end transaction"... as I recall, deposits are automated, receipts are printed, and stuff like that... Looks like the machine tracks the submission, keeping the process open, and has a timeout after 20 seconds (5 of the transactions were card swipes, people probably checked the balance and left, timed out... one transaction had a different status code after about 10 seconds, im assuming it was a 't.cancled' as there was a new card that same instant.) One kid put two 5's and four 1's, 5,1,1,5,1,1... as I recall, dinner is 7$ on mascotPoints... Someone visiting? There's also a two-10's, two-5's, sequence of 1's (aargh) and two-20's... Great... We've got one shot to rock, otherwise a false/error transaction is gonna cause some problems... so lets hope we can spoof the target money eater WITHOUT the device realizing it or speaking up for its rights... I really dont want to go back out there and hurt the machine, its unethical to destroy stuff, and counterproductive for long-term entertainment... Though the RA chickie was kinda hot -- ya, i swing... yellow t-shirt under the leather... ;) The machine looked kinda old, so im gonna bet its a cause-effect system, ignoring incorrect signals addressed to it, plus it has no awareness of time on the coms link, if Im wrong here, I just wasted a fool hour and a half on this process... The program was a different issue, its modular, with plugins, and uses data files for each target protocol, etc, so well worth the 3 hour effort ... even has a visualization screen and tchit... bleem that, biiiatch... So, im gonna go on a blade edge and assume the money eater will NOT respond to a spoofed signal supposedly from it, and will NOT respond to a core response, if it has no timer, then assumably there is no concern for the timing of the polling, endpoints could be added or removed, transactions take time, its assumably a instantaneous system... ie "WAIT" state... (lines are busy) Im assuming the machine only has a cause-effect mentality, so it can byte itself... Possible other problems... If my sync is off (with a sub-ms timer at 9600 baud, thats hard to do) then its gonna desync and generate errors... if i overlap another device, could cause all types of ruckuss... ya, we COULD go check the specs on the protocol, but that would be conventional... So... lets see if we can spoof the signal for the 20's on her account earlier... highlighting transaction, which now has been thoroughly broken out given the AI model i fed the program in creation (had some idea of the data layout), and telling the spoof that the two 20's are coming again, hoping the negotiations and response are identical... if this fails, we whitewash that laptop and try again (nothing lost thus far) sometime later... got all the data here... if god forbid, the response timing is off, or something screws up, im gonna be annoyed... this is a primitive system yaknow... notes... all headers from the thing were identical, no timestamp or crc or counters, basic format [device][userID][CMD][values/etc]... responses were identical... [device][OK][raw data, like text bal in the laundry] -- the coke machine #1 was told to say "have a nice day" #2 said "have fun vacation" ... "me food eat" "me you exploit" "dumbfux" So... queing initial sequence... timer is synchronizing -- making sure theres no other activity... getting back a sequence of responses... exact timing (the core is obviously a computer, not the time-delay for the tape drives in the 1984 design) result: chickie has an extra 40$... its a free world! Now, obviously audit is gonna be confused when the machine is missing a few bills... so let's make it obvious... :) I hear tech staff is off for break as well... skeleton crew at the campus... number ranges for the ids seem to be within [a scope] well, in case things go stray, lets que our 100 first (this one is a xxxxx27) so even if there's some type of security interlock, it will probably get through... I have a speed control, and the confirmed responses from the core are now scripted in the algos in the proggie... lets try a slow cycle... legitimate intervals... first set of 100... scripted... go! STRANGE RESPONSE x03 --- probib "does not exit" ... another one on 34... 72... tchit... well time to fix that... dag, maaahn... kid x40 has like 2k$$us on his card... hmmmmm... we'll think about that... I know i've got a electromagnetic card writer somewhere, and i got a card... hmmmmm picture even looks like me... ok, analysing 'error' responses... completed... error was generated on the first command... supposed to NOT take money for a non existent account... even had plaintext "account disabled" ... doh -- little red letters baaahbie... ok, looks clean... I pre-programmed a timer cycle, if things screw up from now on, proggie will cycle... once it completes the script, or if it looses connection with my control console, it destroys itself and the computer... all the basic stuff... so... looks like the numeric distribution of the IDs are diverse, so lets run a brute force cycle... Sets of 100, sequentially, randomly distributed, ai timers, starting with MY set again... hehe ok, quing scripts, randomizing xxxx100 sequences, anything more than 2 twentys would generate attention, if twenty to everyone doesnt -- hehe GO! (cycle repeats after its done, ignoring/skipping bad ID#s, and reporting ballance:id:data to the recon server over in .ru -- i'll get it later, if i care) Time for food... Yaknow, that pizza place right out side of campus? That kid never got out much, so I doubt they'll care or notice, its busy now too... Food is good, my reciept says "Ballance $74.43" --- pizza meal was 5.95$$us, original account balance was like .38 cents or something... Im out... Toodlez till l8r ;) " -Rabbit@DeathsDoor.com Concerns: Does the simulated device have a crosscheck on its own identity? In most simple devices, this is an unneccessary expense, but if it does, and you falsify its identity, it's gonna call you on it. Alternately: Alternate uses: falsify a laundry signal, whilest sitting in the laundry, tell the mob guy that 'that lame kid' has 3,000$$us in his mascotPoints account... how? the reply signal had the value of the account balance. MSG me any other ideas ;) Im sure we can write up another set of simulations for this process... I'd be curious any written discussions of this conceptual model of the exploitation of bad system designs... Any and all responses will be conceptualized and included in follow-up supplements to the course. Have a nice day ;) -Rabbit@DeathsDoor.com ---PGBRK Teacher's Guide to teaching Wire Phreaking 101: WEEK TWO. by Rabbit@DeathsDoor.com - April 2003, Week 2. WEEK TWO. This is the second week's handout, of a 3-week course WP101. As you recall from last week, you had a 1-day lecture session where you covered the basic understanding of one variety of line exploit, and designed some basic tools to assist in that process, and submitted the grocery list for procurement. The second day last week, you further optimized the code for your program, and built the physical device, then began testing with the lab setup provided to you as a target. The third day, you completed your exploitation simulation, and discussed in distributed workgroups the pro's and con's of various techniques, as each representative from each development team presented their findings to the work group. Also this third day, you discussed the logistic and ethical aspects of your findings. Lab reports or technical analysis are optional. Granted, some student designs from last week were unsuccessful, others generated faults which triggered a security audit by the target, but at least a proportion were completely operational and successful. This week, we will discuss a number of enhancements both to the physical device, as well as the software that runs it, and contemplate a physical breach with transparent features. Conceptually last week, you utilized a mono audio control for input and output in the last simulation, and it worked well, however with some designs there was conflict between two identical devices (spoof and real) and a large number of accounting faults due to the lack of physical $$ in the money eating machine. This week, we will realize that both the mic/lineIn and spkr/out are STEREO, and that physical isolation and control of the money eater or other target device could allow for a CLEAN and TRANSPARENT compromise which maintains logistic and audit/security integrity. Your software program from last week has been refined and now operates desirably in all contexts, you have basically emulated the on-chip software of the various devices, and begun to install advanced analytical capabilities and modular functionality into your program. In short, if your target is to remain clean in all regard, and the financial processing/audit staff are to be unaware of the inconsistency between accounting and physical materials (cash), you may want to learn how to isolate the target device and falsify communications both to it, as well as from it. On one channel of your stereo input (there was no reason to analyse two or more channels for input, as that wastes computational capabilities) you have the incoming feeds from the main core system, and the corresponding output back to the wires. You understood that the target device was oblivious to false signals, and worked under that assumption. Now, you will upgrade your interface systems to completely MIM the target system, allowing for control both of the entity of the target as perceived by the core, as well as the physical target device. This is a significantly more complex task, however it equates to approximately double the runtime code and hardware needed. If designed properly, your software's capability will already be able to accommodate infinite input and output channels, each independently timed and cross-synchronized, allowing for multiple targets to be addressed simultaneously. You should also be capable of accepting OTHER data feeds, possibly an RS-485 to RS-232 converter, or other analogue-binary signal readers that you may create. Granted intercepting/reading IP communications to the relay device is another approach, it should already be encrypted, and by definition, Phreaking is the analysis of an analogue signal (in this case carrying binary data). Signal INT such as tapping ethernet or optical or similar wires are not covered in this specific course. Use of non-physical techniques (inductive pickups, radio signals, remote modulators, etc) are also not covered. This IS WP101 ;) In your forthcoming primitive design, you will be controlling two interfaces with the obvious two targets. You have isolated ONE device on the outside link (right channel) and the original core link on the left channel. For this scenario, we will assume that your target device (money eater) is on the end of the chain, although you should have no problem applying these concepts to an entire set of them. You are basically creating both a new core (as perceived by the devices) and a spoofed device (or set of) as seen by the core. For this pursuit, which is known as an 'attack' rather than an 'exploit', (mainly because you are physically compromising a system, rather than simply working in parallel to it) you will be physically decoupling the target device from its host system. Note: a certain schoolchild is under a gag order because he 'attack'ed a laundry machine as of mid-April 2003. If you are curious, you may want to review the logistic implications and differences between the methods and logistic protections for "Reverse Engineering" versus 'attack'. DMCA's assinine antics come to mind. Memories of hell 2000.07.01-08 ;) The process of isolation is simple, it begins with your standard wire-exploit technique, where you connected a listening and talking circuit to a wire. Here, though, your goal is multifaceted. Not only must you physically disconnect ('hurt') the device to isolate it, you must do so in a manner which is NOT detected by the controlling system. As you are well familiar, the core uses a polling technique to request a status response from the various devices. If this response is not received, the core generates a fault and indicates the non-existence of the device. This happens more than once, it should notify the human tech staff. With 16 units at 9600 baud, especially with a small-size data packet, it can be assumed that the cycle happens numerous times per second. It takes me approximately 5 seconds to completely cut, strip, and tie the ends of 2-now-4 wires. Your analysis system and software needs to maintain the consistency of the data feed between the devices, it MUST transfer the data flow between the core and target in realtime, allowing for realtime operation of the system. If there is ANY computational delay or other faults in the MIM device, its presence will NOT be transparent. In order for the MIM to be completely competant, it must be fully aware of the timing and sequencing of the line data, it must also be able to both serve as a RELAY between the soon-to-be independent systems as well as capable of changing the data in realtime between the target/exploit and core. Thus, its operation and configuration start as identical to the "Listening" mode of the earlier device, once it is suitably comfortable with the target system, then the two channels/sides/ends/etc can be delinked and pumped through the relay device. Obviously, an appropriate physical installation would be to clip one set of leads (which in the complex circuit design, means listen/talk wire per each target wire, one set each for target and core target sides of the wire.) to the left side of the wire, toward the physical target, and one to the right side of the chopped wire, toward the core target. Just in case you are REALLY dumb: C__/-RIGHT=X`==========;\ \-LEFT=X`==;\ \ \ | | | | | \, | \, (target)===:::::===8 8===:::::===(core) OK... you got the computer connected to two parallel interfaces, one is connected to the core circuit, the other to the target device, there's a cut in the middle of both wires. Perhaps (if you didnt figure it out last week) those tic marks on the X (interface device) happen to be links to the power and ground of the target, but of course, we didn't tell you that, you knew how wires work already. Back to reality, whoops there goes gravity --- NO! Thats the intro course to field effect dynamics and assemetrical capacitors which similarly teaches you how to easily create an anti-gravity device. Course "TheLifter 101" Go sign up! I heard the Rabbit@DeathsDoor.com is running it! Anyways. Dont need to fly away until after you complete *this* course, right? So, you have a basic MIM device, it simulates the physical target to the core, and simulates the core to the physical target. So, how can it be used? Can you completely simulate EVERY device you have access to? Can you compile an inventory of command sets, protocols, and whatnot for every system you have an interface to? What about logging and simulation? If you can watch that person go through 3 levels of security every few minutes, why cant you spontaneously open all the doors for him before he gets there? God the games are endless... In the lab of course ;) Why not work to understand the problems with the system, and generate some ideas on how to make it (or your replacement product) better? This is what is know as basic "Reverse Engineering" ... You simply sat there and looked at a thing, you happen to have recorded the core, and then independently plugged in the various target devices, thoroughly tested them, simulated any possible conditions, and understood how they worked. Neato! Theoretical Simulation: ========== (below is incomplete.) Rabbit@DeathsDoor.com [put stuff here... fake money acceptance, credit wrong account, give correct response, keep taking their money, randomly distribute it... intercept door controls, "But the system says everything is locked and closed!" "Then why are all the heavyweight ultra-secure doors wide open and moving on their own?" "I dunno"... Apply that to secure environment contexts... etc...] PRELIMINARY... then cover the discussion of RE ethics, etc... aarf. So how could you make the target system better, and less simple to fk with? Ethics discussions... yaaaah... half done finally. Took an hour to write... sheesh. =====