Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
I have a friend, Mike* (not his real name), who owns a 1983 Firebird. He does a great deal of work on cars in his spare time, but his education and job are in computer science. The work that he generally does is in microcomputers and microcontrollers. Mike was interested in improving the performance of his Firebird, and happened to have a friend John* (not his real name, either) who worked for GM and had access to the design and coding for the car computers. John was willing to provide this information to Mike as a personal favor, and did so. There is a PROM in the car computer that contains the basic parameters of the engine's operation, such as fuel mixture, ignition advance, temperature compensations, etc. If I remember correctly, the PROM is a type which is pin compatible with an industry standard EPROM (i.e., the EPROM can be programmed and inserted directly into the PROM position by changing only one or two power supply pins). The information in the PROM is not necessarily set for the highest engine performance, but rather to meet federal emissions control and fuel economy regulations. Therefore, changes in the parameters in the PROM could substantially improve the engine performance, to the detriment of compliance with federal regulations. Mike proceeded to replace the PROM with an EPROM of his own programming. This resulted in a considerable improvement in the performance of his Firebird. After making this modification and adding exhaust headers to the car, it had a top speed in excess of 150mph. (After reaching 150mph on an interstate highway, Mike decided he really didn't want to know what the top speed was.) I don't recall what the top speed was before these modifications, but it was a good deal closer to 100mph than 150mph. * "John" does not wish to be harrassed by his employer. "Mike" does not wish to be harrassed by the government for modifying polution control on his car.
One risk of computers that I haven't seen addressed in this forum is the risk of having your cpu fall on you. This comes from a man who several months ago had the experience of an 11/45 falling on his foot. anthony a datri cmu computer club
The information concering the kidnapping, shooting, and release of the 6
other inmates is correct, however the rest of the information is misleading.
The guard tower was being staffed only during daylight due to financial
restrictions at the time of the escape. Now it is being staffed 24 hours a
day. Although the guard tower was unmanned at the time, it was not in the
field of view where the prisoners scaled the fence. That area of the fence
was being monitored by motion detector sensors which were attached to a
computer system. Due to several false alarms, it was decided to disable
that portion of the monitoring area until the problems were solved. Also,
the fence was NOT topped with the normal razor that surrounds the rest of
the fences. The escape area was still under construction. The 18 foot high
chain-link fence was also not covered with a fine mesh fence which made
climbing the chain-link fence trivial. Normally, the fine mesh makes it
near impossible to get a good hand or foot hold on the fence. It has also
been mentioned that there are some design flaws in the computer surveillance
system as well as the fence enclosure.
The combination of weaknesses is what made the escape possible. At present,
only one inmate has been recaptured the other six are still at large, and are
suspected of traveling south towards Mexico. Recent sitings have confirmed
this suspicion.
James Lujan (aka Jewel)
I know (personally) of one case where one of my ex-students decided that he needed free long distance. He would use his Apple-II (it was some time ago) to dial up the local number and try some number as an access code. He called the school's computer, so he knew that if he got a carrier then he had gotten through. To make a short story even shorter, he used sequential probing to choose the access codes. The long distance company's computer (it wasn't Sprint, he'd gotten away using their's for a long time) picked up on the sequential probing. The next thing he knew there were police wandering around his house late at night. A week later he was arrested and his computer taken away (what a terrible punishment!). The funny thing was Pac-Bell was after him to give them his "source" and find out where he had gotten the sophisticated algorithm, etc. It seems they thought he was a big time phone cracker. Darrell Long UUCP: darrell@sdcsvax.uucp Department of Computer Science & Engineering, UC San Diego, La Jolla CA 92093 Operating Systems submissions to: mod-os@sdcsvax.uucp
I was reading the Wall Street Journal last week, and noticed a
full page ad for the new US Sprint "FON Card." The ad included a
picture of a sample card. I tried making a US Sprint call using that
card number, and it worked. Further investigation revealed that ANY
fourteen digit number would allow calls to be completed.
In this case, the problem was fixed by the next afternoon. But
Sprint is not always so prompt. I once called them to request deactivation
of a code, telling them that the security of the code had been compromised.
They told me that it would take at least a week to deactivate the code.
US Sprint and the other companies claim to lose a lot of money
from theft, but they are evaluating those losses based upon the retail
value of the unauthorized calls.
It is only reasonable to use retail value for calls that
people would have paid for otherwise. Most people I know who (would)
use unauthorized long distance codes would use them only for calls
which they would not have made otherwise. The real cost of the
unauthorized codes, then, is simply the long distance company's
marginal cost, which is negligible.
The fact that the Florida gentleman received such a large bill without
warning is quite suprising. Recently, my sprint access code made its way
to a similar hacker's BBoard. Within days, US Sprint called me, told me what
had happened and that they were actively tracking (tracing?) the sources of
the phone calls. Seems that they computer systems automagically picked up on
calls being made very closely spaced in time from many different cities and
that they did not fit out 'usage pattern'. When my bill came out (all 30 pages
worth) there was a nice letter saying to 'just pick out the calls you KNOW are
yours' which was easy since my calls all originated in Salt Lake City.
They specifically wanted the access code left live until they could
try to track down the callers who were using it. They just called the other
day and informed me of the new number and that of the several thousand dollars,
they had recovered a great deal of it....All in all, they did a good job of
keeping the customer happy and well informed, and impressed me with the
capabilities of their software to extract features that indicate abuse.
-ed cetron
>... has eluded foreign experts. The so-called virus has been held responsible
>for a string of computer disasters in several countries since it was first
>detected in a NASA system in the United States in 1985.
This is news to me (unless it's a mix-up with another incident). I would
appreciate any evidence to elaborate. [Location, system type, etc.]
--eugene miya, NASA Ames Research Center, eugene@ames-aurora.ARPA
{hplabs,hao,ihnp4,decwrl,allegra,tektronix,menlo70}!ames!aurora!eugene
In reference to the reason for disconnecting the negative terminal of a
car battery: Have you ever touched (accidentally) the frame or sheet metal
with a wrench while disconnecting the positive terminal?
Disconnecting the negative (ground) terminal first is a safety precaution
for the mechanic to avoid inadvertantly shorting the battery to ground. After
the negative terminal is disconnected the positive terminal may be brought into
contact with the frame without ill effects.
steve
Steve Mahan, Naval Coastal Systems Center, (904) 234-4224.
Standard disclaimer applies.
> From: <PRITCHAR%CUA.BITNET@wiscvm.wisc.edu> > Subject: BALANCE OF POWER > Note that 45 years ago, the Japanese war-gamed their intended attack... There were several Japanese simulations of the attack on Midway. The first simulation took into account the Japanese forces, the American forces, relative skill levels, and the like. The simulation was played, and the result of the simulation was that the Japanese lost. This was unacceptable to the admirals, since they knew that they had a superiority in force strength, better intelligence, and the advantage of surprise, so they ordered the rules of the game to be redesigned. After a couple of iterations, playing the simulation produced a Japanese victory in line with what the admirals expected from their plans. The attack was carried out according to the final simulation, whereupon the accuracy of the initial simulation was proved, with the Japanese losing most of their carrier force and being unable to conduct a landing on Midway. Sean Malloy, Naval Personnel Research & Development Center, San Diego, CA, 92152-6800 (VOICE) (619)225-6434 (soon to be malloy@nprdc.mil)
In Risks 5.8 Don Chiasson notes the problem of hardware bugs, and makes the
statement "it is not possible to prove the correctness of hardware". This is
only partially true. A group at the University of Calgary has recently
proven the correctness of a chip design and is continuing research in the
area. (Anyone interested in the references can send me mail, although I add
that I am not associated with this group). As for the testing of chips once
the design has been verified, Mr. Chiasson is on target, as the majority of
testing schemes attempt to minimize the number of defective chips released,
rather than ensure that all are fault-free.
Rob Aitken Alberta Research Council, Calgary AB
UUCP: ...{utai,alberta,ubc-vision}!calgary!arcsun!rob
In response to Don Chiasson's 6 July 87 comment "it is not possible to prove the correctness of hardware". Clearly exhaustive testing is not a practical means to accomplish this. But see: Hunt, Warren A. Jr., "FM8501: A Verified Microprocessor", Tech. Report 47, Institute for Computing Science, University of Texas, Austin 78712, February 1986. This is Warren's dissertation and describes the formal specification and definition of a microprocessor (similar in size and complexity to a PDP-11) and provides a proof that the formal definition satisfies the specifications. Essentially a set of mathematical operation are defined that describe the specification of the machine and these operations are shown to be equivalent to a graph of hardware gates. The mathematical operations are characterized by commonly used functions, such as addition, subtraction, and shifting. The implementation (gate graph) is characterized by Boolean functions applied to components of bit-vectors. The machine was specified and defined in the Boyer-Moore Logic and the proof was done using the Boyer-Moore Theorem Prover. A brief, but more readily available description can be found in Bevier, Hunt, and Young, "Toward Verified Execution Environments", in Proceedings 1987 IEEE Symposium on Security and Privacy, April 1987. This work is currently being continued at Computational Logic Inc. - Michael K. Smith
Please report problems with the web pages to the maintainer