Discussion:
RFID chip barcodes can carry a virus
(too old to reply)
Winston Smith
2006-03-16 03:01:38 UTC
Permalink
<http://news.yahoo.com/s/nm/20060315/tc_nm/barcodes_dc>
Radio chip barcodes can carry a virus: scientists

AMSTERDAM (Reuters) - Cheap radio chips that are replacing the
ubiquitous barcode are a threat to privacy and susceptible to computer
viruses, scientists at a Dutch university said on Wednesday.

Researchers at the Amsterdam's Free University created a radio
frequency identity (RFID) chip infected with a virus to prove that
RFID systems are vulnerable despite the extremely low memory capacity
on the cheap chips.

The problem is that an infected RFID tag, which is read wirelessly
when it passes through a scanning gate, can upset the database that
processes the information on the chip, says the study by Melanie
Rieback, Bruno Crispo and Andrew Tanenbaum.

"Everyone working on RFID technology has tacitly assumed that the mere
act of scanning an RFID tag cannot modify back-end software and
certainly not in a malicious way. Unfortunately, they are wrong," the
scientists said in a paper.

"An RFID tag can be infected with a virus and this virus can infect
the back-end database used by the RFID software. From there it can be
easily spread to other RFID tags," they said.

As a result, it is possible that criminals or militants could use an
infected RFID tag to upset airline baggage handling systems with
potentially devastating consequences, they said.

The same technology could also be used to wreak havoc with the
databases used by supermarkets.

"This is intended as a wake-up call. We ask the RFID industry to
design systems that are secure," Tanenbaum said in a telephone
interview.

INTERNET OF THINGS

RFID has been touted as "The Internet of Things," in which anything
from shampoo bottles to marathon runners can be tracked using radio
tags.

Civil liberty groups say RFID could lead to an unacceptable invasion
of privacy and argue that airline ticket information could be used by
law enforcement agencies and divorce lawyers.

Metro (MEOG.DE), Germany's biggest retailer, said at the CeBIT
technology trade show it plans to save 8.5 million euros ($10.1
million) annually by using RFID to track stock from suppliers and at
its flagship Future Store in Rheinberg town.

Industries in which tracking goods is crucial such as pharmaceuticals,
governments, logistics, airlines and manufacturing already use RFID
technology.

A recent study by ABI Research found that 10 drug products are
expected to have RFID tags on a large scale this year.

The cost of making an RFID tag is about 14 euro cents today and needs
to fall, Metro's head of technology Gerd Wolfram said.

But Ian Furlong, manager of Intel's Solution Services division for
Central Europe, said at CeBIT that the price of RFID tags was "rapidly
falling toward the 5 euro cent mark."

Andrea Huber, managing director of Informationsforum RFID, a German
group raising public awareness about the technology, said most
companies were waiting for the price of tags to fall to 1 euro cent
before they start widespread use.


--
W§ mostly in m.s - http://members.1stconnect.com/anozira
CanopyCo
2006-03-16 13:57:11 UTC
Permalink
First off, this diminstrates that the transmition from the chip is more
then just a bar code type serial number that is cross refferenced to a
database, or even a txt document that is simply read.

Why they would make the transmition a exicutable program, I have no
idea.
Nore can I think of a reasion that they would make the readder exicute
any program that it read from the chip.

I am starting to now question the validity of this report.

The part about
Post by Winston Smith
Civil liberty groups say RFID could lead to an unacceptable invasion
of privacy and argue that airline ticket information could be used by
law enforcement agencies and divorce lawyers."
is crap.
The chip has nothing to do with these guys being able to use airline
ticket information. They can do that now without the chip.
Offbreed
2006-03-16 14:50:03 UTC
Permalink
Post by CanopyCo
First off, this diminstrates that the transmition from the chip is more
then just a bar code type serial number that is cross refferenced to a
database, or even a txt document that is simply read.
Nope. All that's sent is bits and bytes, and anything short enough to be
recorded can be on it. Data, text, programs, spam, viruses, no matter.
Think of the RFID signal as being something sent to a computer over the
internet, except the computer cannot talk back (for now). What comes to
you over the net can be about anything, right?

Right now, the RFID devices have a small enough payload so getting a
virus in there is hard. Sooner or later, people are going to want to
make those things carry a couple KB, and we will see the virus problem
start.

Then someone is going to think of something a two way RFID device can do
for him, and that's going to be when malware takes off.
CanopyCo
2006-03-16 19:43:30 UTC
Permalink
Post by Offbreed
Post by CanopyCo
First off, this diminstrates that the transmition from the chip is more
then just a bar code type serial number that is cross refferenced to a
database, or even a txt document that is simply read.
Nope. All that's sent is bits and bytes, and anything short enough to be
recorded can be on it. Data, text, programs, spam, viruses, no matter.
Think of the RFID signal as being something sent to a computer over the
internet, except the computer cannot talk back (for now). What comes to
you over the net can be about anything, right?
Exactly.
For example, if you send me an excitable file or a text file, all you
do is send me a bunch of 1's and 0's.

What I do with it at my end is the thing.
If you send me a bunch of 1's and 0's that is a computer virus or a
program that tells me the time, all I get is still a bunch of 1's and
0's.
If I open it as a text file I get the source code in machine level of
the software that you sent me if it is a program and the machine level
of the ASCII alphabet if it is a text file.

I would have to run the program that you sent for it to do anything
once I had it.

MS automatically runs some things now.
That is how viruses work.

Now, if I am only expecting a txt message from the chip, then why would
I run it as a program?

It is supposed to be just some little bitty serial number that is cross
referenced to a database, so why would they try to run that?
Post by Offbreed
Right now, the RFID devices have a small enough payload so getting a
virus in there is hard.
Getting it in there is not the thing.
Getting it ran after they send it is the problem.
What they would get from the scanner would be gobble goop.
Like opening a Word document with a Note Pad program.

Sure, if you open it with Word, you can get problems, but with notepad
the file cannot execute its orders and all you get is junk.
Post by Offbreed
Sooner or later, people are going to want to
make those things carry a couple KB, and we will see the virus problem
start.
Then someone is going to think of something a two way RFID device can do
for him, and that's going to be when malware takes off.
Still, not if all the reader does is read it as a text file and then
send it back another, updated text file.

Only if the reader executes commands form the chip will it ever be
capable of having virus problems.

And why would they do that?
j***@gmail.com
2006-03-17 00:07:29 UTC
Permalink
->"An RFID tag can be infected with a virus and this virus can infect
the back-end database used by the RFID software. From there it can be
easily spread to other RFID tags," they said.

->As a result, it is possible that criminals or militants could use an
infected RFID tag to upset airline baggage handling systems with
potentially devastating consequences, they said.

->The same technology could also be used to wreak havoc with the
databases used by supermarkets."
------

There are two types of RFIDs - active and passive. Active RFID's use
battery power, whereas passive RFIDs are 'powered' by the signal they
receive from the transceiver (aka 'reader'). Passive RFIDs are by far
the most common in large scale data tracking due to their cost
efficiency, and long data retention (aprox 10 years). Active RFID's
can only be used in situations where the battery can be replaced - thus
eliminating baggage tracking, personal identification (in credit cards,
DL's, under the skin etc), and most large scale applications.

One of the characteristics of a passive RFID is *it cannot be written
to by the transceiver*, but rather a special 'writer' is required.

So, even if a RFID coded with a virus were be scanned by the
transceiver, it would be impossible for the transceiver to in turn
spread the virus to other passive RFIDs. But would it even get that
far? Considering RFID networks are built to only scan data, not
execute code, it would be no different than trying to scan a 'foreign
barcode' at a store - the reader/transceiver doesn't recognize it as
valid data (what has been programmed as 'expected data') and throws it
away. Try it sometime - take a unique barcode from one store and scan
it at another... does it cause their database to crash? If it does...
they need to seriously reconsider a database redesign....

a barcode is only a simple representation of 'data' using light and
dark spaces. How the scanner interprets it is much like binary - dark,
dark, light, dark, light, light, dark... etc. It is then translated
into... no less than 1's and 0's. So could a simple virus be placed in
a barcode?
j***@gmail.com
2006-03-17 00:12:30 UTC
Permalink
might I add, active RFID's have already increased to a capacity of
1MB... quite enough space for a virus if it was possible.
Offbreed
2006-03-17 02:06:23 UTC
Permalink
Post by j***@gmail.com
One of the characteristics of a passive RFID is *it cannot be written
to by the transceiver*, but rather a special 'writer' is required.
This is true, for now.

The "for now" part has me watching. What is the RFID device going to
develop into?
j***@gmail.com
2006-03-17 04:14:17 UTC
Permalink
Post by Offbreed
This is true, for now.
yah, "for now" leaves alot open for the future.

Except, they're that way by design. If they were meant to be written
to on the fly, they would have just incorporated the writer with the
transceiver, as I'm sure they've done in other cases with the active
RFIDs. They have no reason to though, because for the purpose of
tracking and 'sending' information (which is the intended use of
passive RFIDs), they have no need to write to them. Thus the article is
pointing fingers at a dead duck.
Offbreed
2006-03-17 14:30:52 UTC
Permalink
Post by j***@gmail.com
Thus the article is
pointing fingers at a dead duck.
<G> Yup. I doubt if the RFIDs on underwear will be active.

The active RFIDs will (gazing into crystal ball) require less energy to
record so the interrogation signal can power it, and have to become much
more complex, with computational ability, to prevent random signals from
reading or writing to memory. Sort of like USB drives with a tiny,
hardware firewall, hooked to a short range WI-FI. Seems sort of obvious,
to me.
Winston Smith
2006-03-19 20:30:47 UTC
Permalink
Post by j***@gmail.com
Post by Offbreed
This is true, for now.
yah, "for now" leaves alot open for the future.
Except, they're that way by design. If they were meant to be written
to on the fly, they would have just incorporated the writer with the
transceiver, as I'm sure they've done in other cases with the active
RFIDs. They have no reason to though, because for the purpose of
tracking and 'sending' information (which is the intended use of
passive RFIDs), they have no need to write to them. Thus the article is
pointing fingers at a dead duck.
From the article
"Researchers at the Amsterdam's Free University

created

a radio
frequency identity (RFID) chip infected with a virus to prove that
RFID systems are vulnerable despite the extremely low memory capacity
on the cheap chips."



The point is that bad guys don't follow the official rules. They can
build a chip with anything they wish in it. The objective is
malicious - to crash large computer systems.


--
W§ mostly in m.s - http://members.1stconnect.com/anozira
CanopyCo
2006-03-19 21:31:56 UTC
Permalink
Post by Winston Smith
Post by j***@gmail.com
Post by Offbreed
This is true, for now.
yah, "for now" leaves alot open for the future.
Except, they're that way by design. If they were meant to be written
to on the fly, they would have just incorporated the writer with the
transceiver, as I'm sure they've done in other cases with the active
RFIDs. They have no reason to though, because for the purpose of
tracking and 'sending' information (which is the intended use of
passive RFIDs), they have no need to write to them. Thus the article is
pointing fingers at a dead duck.
From the article
"Researchers at the Amsterdam's Free University
created
a radio
frequency identity (RFID) chip infected with a virus to prove that
RFID systems are vulnerable despite the extremely low memory capacity
on the cheap chips."
The point is that bad guys don't follow the official rules. They can
build a chip with anything they wish in it. The objective is
malicious - to crash large computer systems.
That does not change what the reader is expected to do with the
information that it receives.

It should not be running anything it receives.
It should be reading the 1's and 0's as data and just disregarding
anything that it did not recognize.

Just like opening an exe file with notepad.

If it isn't, then it would be a simple change to make it that way,
though I have no idea why it would be anything other then that already.

I still think that this article is more propaganda.
Especially with the blurb about chips allowing government to track
airline tickets.
They already do that without the chip.

Caught in one lie.
Makes the rest questionable.

Try this.
A virus is a executed program.
It has to be ran, either directly or by some other running program.

Now, pick out some exe file on your hard drive.
Just in case, copy it to somewhere and rename it test.txt.
Now, open that file using notepad.

If it was a calendar program (for example), did a calendar suddenly
appear on your screen?
Nope, what happened is that you got a bunch of unrecognizable crap at
best.
Or note pad shut down and said that the file was unopenable.

That is what a virus would be expected to do if downloaded form a chip.
J. Francis
2006-03-20 10:45:02 UTC
Permalink
Post by CanopyCo
Post by Winston Smith
The point is that bad guys don't follow the official rules. They can
build a chip with anything they wish in it. The objective is malicious
- to crash large computer systems.
That does not change what the reader is expected to do with the
information that it receives.
It should not be running anything it receives. It should be reading the
1's and 0's as data and just disregarding anything that it did not
recognize.
First of all, I'd like to remind people that for may years people swore up
and down that you couldn't get infected by a virus from simply looking at
a graphic image. We all know that to be not quite so true today. ;-)

It's not necessary for something to be designed to explicitly execute data
it receives. It can be forced. It's called a buffer overflow, and it's
inherent to almost all digital equipment that can execute instructions.
The underlying principal is stuffing too much information into a "box"
that's not designed to hold it all. Because memory is handled in segments,
if a piece of data is too large for the segment designed to hold it, the
excess can "spill over" into other areas. Occasionally those other areas
are segments earmarked for execution by the operating system, or even the
hardware.

As a crude example let's assume that an RFID reader was designed to accept
a code from an RFID tag of 8 digits in length. The code 12345678 is
perfectly valid. Now lets say the RFID tag sent 12345678execute-virus. The
extra data "execute-virus" has to go somewhere, and in some cases that
"somewhere" might be a location of memory that's currently pointed to by
an instruction pointer. Consequently that harmless extra "data" is
magically transformed into executable code, and executed.
Post by CanopyCo
Just like opening an exe file with notepad.
It's not like that at all, although it's possible to crash Notepad and
even Windows by opening certain data. I also recall an old exploit that
was triggered by trying to print certain data from within Notepad, oddly
enough because when Notepad was formatting certain "text" for printing
that carefully crafted text exploited a buffer overflow vulnerability.

The act of printing shouldn't execute anything that's to be printed,
correct? :)
Post by CanopyCo
If it isn't, then it would be a simple change to make it that way, though
I have no idea why it would be anything other then that already.
If you were a coder you'd be singing a different tune entirely. If you
were a historian of computer security, you'd know the numbers of such
vulnerabilities have probably reached the hundreds of thousands by now.
Bounds checking and validating data is an imperfect science. Almost an art
form.

I'd wager another 20 or 30 potential buffer overflow vulnerabilities have
been reported on the Full Disclosure and BugTraq mailing lists just this
past week. It's like herding cats sometimes. And as programs and hardware
get more complex, bugs and errors become more prevalent. :(
Post by CanopyCo
I still think that this article is more propaganda. Especially with the
blurb about chips allowing government to track airline tickets.
They already do that without the chip.
I think the article was saying it was going to be an easier, or finer
grained way of tracking them.
Post by CanopyCo
Caught in one lie.
Makes the rest questionable.
Try this.
A virus is a executed program.
It has to be ran, either directly or by some other running program.
Now, pick out some exe file on your hard drive. Just in case, copy it to
Irrelevant. The fact that "some random executable" can't execute by being
opened in Notepad is meaningless. It's quite possible that a file that
DOES cause Notepad to fail and allow execution exists. That exact behavior
has in fact been observed in other text editors, and to some extent in
Notepad itself.
Post by CanopyCo
somewhere and rename it test.txt. Now, open that file using notepad.
If it was a calendar program (for example), did a calendar suddenly appear
on your screen?
Nope, what happened is that you got a bunch of unrecognizable crap at
best.
Or note pad shut down and said that the file was unopenable.
That is what a virus would be expected to do if downloaded form a chip.
And that is potentially the problem, although the chances of having it
spread back to other RFID tags is remote. It would require a compromise
that encroached on some other piece of hardware or software that actually
did the writing, and as I understand it, those things are generally few
and far between. Certainly not part of the average checkout-side chip
reader.

Of course spreading isn't the only problem. A piece of RFID malware could
be designed to change a price on something, or change all prices on
everything. That data is held separate from the RFID tag. It might be
designed to collect credit card and PIN information, and transmit it to an
attacker. Or maybe fiddle with medical or police records, or even identity
information in such a way that a real life terrorist could travel places
we don't want them, with a case full of bioweapons hiding behind the
diplomatic immunity of the identity they just assumed.

The possibilities are really only limited by your imagination, and the
access to sensitive data provided by RFID back-end software and
hardware. As RFID becomes more wide spread so does the potential for
compromise of more and more sensitive data.
n***@mytrashmail.com
2006-03-20 13:21:44 UTC
Permalink
Post by J. Francis
First of all, I'd like to remind people that for may years people swore up
and down that you couldn't get infected by a virus from simply looking at
a graphic image. We all know that to be not quite so true today. ;-)
Well for many years it was true that you couldn't get a PC virus from
viewing an image file - until Microsoft's GDIPlus graphics rendering
software included exploitable code which took 2 rounds of patches to fix.
J. Francis
2006-03-20 19:15:02 UTC
Permalink
Post by n***@mytrashmail.com
Post by J. Francis
First of all, I'd like to remind people that for may years people swore
up and down that you couldn't get infected by a virus from simply
looking at a graphic image. We all know that to be not quite so true
today. ;-)
Well for many years it was true that you couldn't get a PC virus from
viewing an image file - until Microsoft's GDIPlus graphics rendering
software included exploitable code which took 2 rounds of patches to fix.
That bug has existed since way back in the Win 3.x days. It's a remnant
of an old method of managing metadata in fact. Old code still hanging
around in new software. It just wasn't *publicized* until recently.

So no, it was in fact not true that you couldn't have bad things happen by
viewing an image file. It really never has been true for essentially the
entire PC revolution and advent of the Internet as a household word. The
flaw was there all along, Microsoft even knew about it, but you just
weren't made aware of it until recently. :(
Offbreed
2006-03-21 02:36:54 UTC
Permalink
Post by J. Francis
It just wasn't *publicized* until recently.
The /type/ of flaw existed, according to the posters in
alt.comp.anti-virus, and it did get covered.

I think there were so few people on the net back in the Win3.X days that
it just did not make much of a splash. More people on the net knew more
about computers, fewer writers trying to write viruses, and the
anti-virus companies got on the problem before it got out of hand.

We have a bigger mud puddle now, so we get a bigger splash <G>.
CanopyCo
2006-03-20 14:49:50 UTC
Permalink
Post by J. Francis
Post by CanopyCo
Post by Winston Smith
The point is that bad guys don't follow the official rules. They can
build a chip with anything they wish in it. The objective is malicious
- to crash large computer systems.
That does not change what the reader is expected to do with the
information that it receives.
It should not be running anything it receives. It should be reading the
1's and 0's as data and just disregarding anything that it did not
recognize.
First of all, I'd like to remind people that for may years people swore up
and down that you couldn't get infected by a virus from simply looking at
a graphic image. We all know that to be not quite so true today. ;-)
Yes, I remember hearing about that.
And that is one more of my gripes toward software writers of today.

A JPG is nothing more then a still photo, rendered on the screen by
lighting up a series of lights (called pixels).

So, all a JPG reader needs to do is go threw a list and light the bulbs
that it said to light.
Nothing more.
Kind of like the peek and poke type of programing from way back in the
old days.
Now, once they realized that someone was using that to "poke" a memory
location that was not a pixel, all they had to do was put in a line
after the reading of the file saying something like If poke > or <
pixel range then goto read file.
Yes, I know, that is not proper code, but you get my drift.
That way it would never try to poke a location that was outside the
pixel range.
Post by J. Francis
It's not necessary for something to be designed to explicitly execute data
it receives. It can be forced. It's called a buffer overflow, and it's
inherent to almost all digital equipment that can execute instructions.
The underlying principal is stuffing too much information into a "box"
that's not designed to hold it all. Because memory is handled in segments,
if a piece of data is too large for the segment designed to hold it, the
excess can "spill over" into other areas. Occasionally those other areas
are segments earmarked for execution by the operating system, or even the
hardware.
As a crude example let's assume that an RFID reader was designed to accept
a code from an RFID tag of 8 digits in length. The code 12345678 is
perfectly valid. Now lets say the RFID tag sent 12345678execute-virus. The
extra data "execute-virus" has to go somewhere, and in some cases that
"somewhere" might be a location of memory that's currently pointed to by
an instruction pointer. Consequently that harmless extra "data" is
magically transformed into executable code, and executed.
Male Offspring of a female canine!!!
And coders have not caught on to this and fixed it after all this time?
That would only require coding in the nature of If input > 8 digits
then truncate to 8 digits.
Yes, again, I realize that this is not proper code, but again, you get
my drift.

The laziness and incompetence of some modern coders is an embarrassment
to those of the old school who took pride in there work.

I do appreciate you letting me know just how they are pulling this
stuff off though.

Thanks.
Post by J. Francis
Post by CanopyCo
Just like opening an exe file with notepad.
It's not like that at all, although it's possible to crash Notepad and
even Windows by opening certain data. I also recall an old exploit that
was triggered by trying to print certain data from within Notepad, oddly
enough because when Notepad was formatting certain "text" for printing
that carefully crafted text exploited a buffer overflow vulnerability.
The act of printing shouldn't execute anything that's to be printed,
correct? :)
Post by CanopyCo
If it isn't, then it would be a simple change to make it that way, though
I have no idea why it would be anything other then that already.
If you were a coder you'd be singing a different tune entirely.
Well, it depends on what you call a coder.
Have written for pay in COBOL, RPGII, and various forms of BASIC for
years.

But my software always aimed at data processing.
Some called me a report generator.

My software ran in the nature of;
Open file "data file" R
Read file #ID Number 8 digits, $name 25 digits, $address 25 digits.
goto do work

If anything was amis there, then you would get garbage on the screen.
And anything to big would just be ignored.

And again, yes, I realize that is not proper code.
I am out of practice and to lazy to look up the proper code just for
this discussion.

Anyway, so, as you can see, I was not of the class doing things like
operating systems and such.
But also am not totally inexperienced in the area.

Thanks for all this information.
Truly appreciated.
J. Francis
2006-03-20 20:00:02 UTC
Permalink
Post by CanopyCo
Post by J. Francis
First of all, I'd like to remind people that for may years people swore
up and down that you couldn't get infected by a virus from simply
looking at a graphic image. We all know that to be not quite so true
today. ;-)
Yes, I remember hearing about that.
And that is one more of my gripes toward software writers of today.
A JPG is nothing more then a still photo, rendered on the screen by
lighting up a series of lights (called pixels).
So, all a JPG reader needs to do is go threw a list and light the bulbs
that it said to light.
Nothing more.
You have a perception of rendering images that's so simplistic it's
erroneous. It completely ignores things like compression and encoding, and
the frame buffered mechanism for lighting up those pixels. Among a LOT of
other things.

In fact your entire argument depends on this sort of oversimplification
and the resulting "that simple" statements that experience, common
sense, logic, and history all tell us just aren't as simple as you want to
pretend they are.
Post by CanopyCo
Kind of like the peek and poke type of programing from way back in the old
days.
No, it's nothing like that at all. :(
Post by CanopyCo
Now, once they realized that someone was using that to "poke" a memory
location that was not a pixel, all they had to do was put in a line after
the reading of the file saying something like If poke > or < pixel range
then goto read file.
Yes, that's called data validation, bounds checking, and/or scrubbing
input. Coders have been wrestling with those things for decades now, yet
as programs grow in line count so do such errors. Often times they're even
inherited from other tools whose authors had no way of imagining the ways
their products would be used, and consequently no way of testing for and
dealing with a particular type of input.

Again, you have an almost adolescent perception of what's involved in
authoring a piece of software. It simply is not as "easy" as you want to
suggest it is to support your argument. And if you believe it is so, the I
suggest you immediately "reform" the whole of the software industry with
your skill and wisdom. You would be made a very rich man in deed. ;-)
Post by CanopyCo
Yes, I know, that is not proper code, but you get my drift. That way it
would never try to poke a location that was outside the pixel range.
I get your drift, it's just that your drift is way out in fantasy land.
It's impossible for a coder to predict every scenario that might be
encountered in the real world, or even every possible input a program
might encounter. And you can't always implement the sort of strict limits
you seem to believe would solve all the world's ills because it would
limit a program's usefulness to the point it becomes unusable or
prohibitively expensive to maintain in a dynamic real world.

Lets say the customers of your RFID company cross some boundary where 8
digits are no longer enough space to encode their entire product line. If
you've hard wired that field to 8 digits you're screwed. You either
replace every reader, or at least its firmware, along with your back end
software and probably all the code that writes the tags too. Since remote
updating of readers and even back end software is a monstrous breach of
security you're stuck doing it "manually", at a huge expense. You either
duplicate hardware, or you pay man hours for someone to do in-person
upgrades.

This is an anecdotal reason why many time thing's simply can not be done
the way you believe they can, even if it *were* humanly possible to
predict every possible future, and catch and squash every single bug that
might creep into sometimes many thousands of lines of code written and
maintained by tens or even hundreds of people. Some of whom you've never
even met and never will.
Post by CanopyCo
Post by J. Francis
As a crude example let's assume that an RFID reader was designed to
accept a code from an RFID tag of 8 digits in length. The code 12345678
is perfectly valid. Now lets say the RFID tag sent
12345678execute-virus. The extra data "execute-virus" has to go
somewhere, and in some cases that "somewhere" might be a location of
memory that's currently pointed to by an instruction pointer.
Consequently that harmless extra "data" is magically transformed into
executable code, and executed.
Male Offspring of a female canine!!!
And coders have not caught on to this and fixed it after all this time?
Coders didn't even know the flaw existed. In the thousands of lines of
code it was a single blip that never showed on the radar. Or maybe they
did know it was there, but found it impossible to correct for at the time,
with the tools they had. Or maybe those tools themselves were the root
cause. Feces occurs...

*shrug*
Post by CanopyCo
The laziness and incompetence of some modern coders is an embarrassment to
those of the old school who took pride in there work.
Now you're just flinging accusations from the position of "armchair
quarterback". If you honestly believe it's so trivial to produce bug free
code then by all means produce something of significance and show the rest
of the world how superior you are. ;)
Post by CanopyCo
Post by J. Francis
If you were a coder you'd be singing a different tune entirely.
Well, it depends on what you call a coder. Have written for pay in
COBOL, RPGII, and various forms of BASIC for years.
But my software always aimed at data processing. Some called me a report
generator.
The coders I refer to are the people who write the software that make your
job possible. Not that report writing doesn't have its Coding aspects mind
you, but the tools you're allowed to use and the types of actions you're
allowed to perform don't lend themselves to self inflicted gunshot wounds
to the feet the way some other levels of coding does. IOW, your report
writing is irrelevant to the subject at hand.
Post by CanopyCo
My software ran in the nature of;
Open file "data file" R
Read file #ID Number 8 digits, $name 25 digits, $address 25 digits. goto
do work
If anything was amis there, then you would get garbage on the screen.
Then you freely admit that you failed in your attempt to write perfect
software even as a report generator! Shame on you. Your "garbage on the
screen" is exactly the sort of failure that might be exploited by a crafty
attacker. Adjust input so that "garbage" becomes valid looking but
incorrect data, and presto... $10,000,000 in company funds accidentally
transfered to his anonymous bank account in the Cayman Islands.
Post by CanopyCo
And anything to big would just be ignored.
And if you can't be aware of the precise size of all possible input when
you're writing your software? Like almost every programmer isn't?

*sigh*

Again, the example was an over simplified example for the sake of clarity.
The fact that you take them so literally while ignoring the real life
problems you should be aware of even as a report writer starts to make
your arguments look a little "uncommitted" to say the least. :(
CanopyCo
2006-03-21 03:08:28 UTC
Permalink
Post by J. Francis
Post by CanopyCo
Post by J. Francis
First of all, I'd like to remind people that for may years people swore
up and down that you couldn't get infected by a virus from simply
looking at a graphic image. We all know that to be not quite so true
today. ;-)
Yes, I remember hearing about that.
And that is one more of my gripes toward software writers of today.
A JPG is nothing more then a still photo, rendered on the screen by
lighting up a series of lights (called pixels).
So, all a JPG reader needs to do is go threw a list and light the bulbs
that it said to light.
Nothing more.
You have a perception of rendering images that's so simplistic it's
erroneous. It completely ignores things like compression and encoding, and
the frame buffered mechanism for lighting up those pixels. Among a LOT of
other things.
Compression:
The act of removing cases of multiple entrees that are the same by
putting one entry and the number that entry is repeated.
Simplified, yes, but basically what it is.
Once you decompress, then you still just light up the lights.

Encoding:
The act of changing data form one form to another.
Is that what you are talking about?
Once you encode / decode it, you still just light up a light.

Frame Buffered mechanism?
Got no idea there, but do know that I could put any picture on a screen
that I wanted to by simply lighting up the correct series of pixels.

Once you do all your fancy stuff, isn't it still just lighting up pixel
# somthing?
I'm really sure it is, as I just took a magnifying glass and looked at
the screen.
Sure enough, just a bunch of little light bulbs lit up in the proper
order.

Not trying to be a smart ass here.
Just trying to understand where my perception is off enough that the
problem could not ever be prevented, no matter how hard you tried.
Post by J. Francis
In fact your entire argument depends on this sort of oversimplification
and the resulting "that simple" statements that experience, common
sense, logic, and history all tell us just aren't as simple as you want to
pretend they are.
Post by CanopyCo
Kind of like the peek and poke type of programing from way back in the old
days.
No, it's nothing like that at all. :(
You light up a bulb on my screen, or you don't.
It is exactly like that.
I can poke memory locations and make any picture I want on a screen,
provided that I do the right bulbs.

Now, how you went about it may have been different, but the end result
is still you lighting up a bulb on my screen or not lighting it.
Post by J. Francis
Post by CanopyCo
Now, once they realized that someone was using that to "poke" a memory
location that was not a pixel, all they had to do was put in a line after
the reading of the file saying something like If poke > or < pixel range
then goto read file.
Yes, that's called data validation, bounds checking, and/or scrubbing
input. Coders have been wrestling with those things for decades now, yet
as programs grow in line count so do such errors. Often times they're even
inherited from other tools whose authors had no way of imagining the ways
their products would be used, and consequently no way of testing for and
dealing with a particular type of input.
One thing at a time.
What other use are they putting JPG readers to other then reading
JPG's?
Sounds like that would be really easy to fix, once one seen what they
were doing to mess it up.
All it does is read a file of a known type, with known data ranges, and
use that information to light up pixels on a screen.
Known ranges.
So why can't they just limit the reader to only dealing in those known
ranges?
Post by J. Francis
Again, you have an almost adolescent perception of what's involved in
authoring a piece of software. It simply is not as "easy" as you want to
suggest it is to support your argument. And if you believe it is so, the I
suggest you immediately "reform" the whole of the software industry with
your skill and wisdom. You would be made a very rich man in deed. ;-)
I can't write that type of software, but that doesn't mean that I can't
see where looking at the problem in a simpler terms could be useful to
someone that can.

I take it that you can write a JPG reader, or word processor, so maybe
you could look at just using code to limit what it would do to only
what it is supposed to be doing.

I have done it in the past with the type of programing that I did back
then.

One such situation was a coder that was talking like you regarding a
help file.
Way to complicated to get the data to only show one subject on the
screen at a time sense it would take out blank lines automatically.
Can't be done.

Until I pointed out that all he had to do was use an underline to fill
in the blank lines so that they stayed where they belonged.

Some times, simple works.
Some times people that are really smart, over look the simple ways to
fix something.
Post by J. Francis
Post by CanopyCo
Yes, I know, that is not proper code, but you get my drift. That way it
would never try to poke a location that was outside the pixel range.
I get your drift, it's just that your drift is way out in fantasy land.
It's impossible for a coder to predict every scenario that might be
encountered in the real world, or even every possible input a program
might encounter. And you can't always implement the sort of strict limits
you seem to believe would solve all the world's ills because it would
limit a program's usefulness to the point it becomes unusable or
prohibitively expensive to maintain in a dynamic real world.
That sounded pretty lame.
Just exactly what is a JPG reader supposed to do other then read a JPG?
And JPGs are pretty well set to known limits.
And my computer manual shows that there are set addresses for things,
like the I/O address for COM 1 is 3F8.
So tell the JPG reader to not effect address 3F8.
Now it will never send anything out that com port, of affect it in any
way.

The areas that you said that it overflows into in order to get the
virus in an area to run is also a known range.
Just tell it to not effect that range.
Smiler coding to when you tell it to effect a memory location when it
is doing its job correctly.

Yes, you are imposing strict limits on the software.
That is the point entirely.
It is limited to only reading JPGs or other known file types.
So now it is only useful for the job it was intended to do.

And I am not talking about predicting every scenario.
Just fix the one that has been around sense Win 3.
Limit a JPG reader so it is only useful for reading JPGs and other
known file types.
That is all I want it to do.
I don't want it to fix coffee, or give you the ability to spy on me.
Just read a file and light up the correct series of lights so I can see
the pattern that was desired when the file was saved.
Post by J. Francis
Lets say the customers of your RFID company cross some boundary where 8
digits are no longer enough space to encode their entire product line. If
you've hard wired that field to 8 digits you're screwed. You either
replace every reader, or at least its firmware, along with your back end
software and probably all the code that writes the tags too. Since remote
updating of readers and even back end software is a monstrous breach of
security you're stuck doing it "manually", at a huge expense. You either
duplicate hardware, or you pay man hours for someone to do in-person
upgrades.
No matter who many digits you set it to, someday it will be over run.
And that is life.
You go buy another one that holds more digits, or you reprogram the one
you have so it now reads more digits.
And alter the software source code that you have to now accept the new
number of digits.
And deal with that number only.
Just that simple.
You don't hard wire anything.
You use a burnable chip, and burn a new program for it and replace the
old one with the new one.
Post by J. Francis
This is an anecdotal reason why many time thing's simply can not be done
the way you believe they can, even if it *were* humanly possible to
predict every possible future, and catch and squash every single bug that
might creep into sometimes many thousands of lines of code written and
maintained by tens or even hundreds of people. Some of whom you've never
even met and never will.
In other words, someone screwed up (bug in software) and no one is
going threw the work to check it out (squash the bug).
Back in my day we called that incompetent (screw up and made bug) and
lazy (did not fix the bug).
Each person should be coding a set job.
And then that job should be checked to see that it worked properly.
Then when a problem is found in a certain area, that jobs software can
be gone to and fixed without having to check out the entire thing.

That's how we did it back when.
Why can't the coders be held responsible for there work now?

And we are still only talking about data input and output.
We aren't trying to change fonts, or make fancy displays.
Just get the serial number, and load it into the proper location so
that we can look up the product and know how much to charge and order
another one.

I could do a chip reader in BASIC and it would never do anything but
read a file and convert it to a display of what it read.
If they can't do it with there newest languages, then do it in BASIC.

Once you get the data off the chip and into memory, all trimmed and
sorted, then you can make it as fancy to look at as you want.
Post by J. Francis
Post by CanopyCo
Post by J. Francis
As a crude example let's assume that an RFID reader was designed to
accept a code from an RFID tag of 8 digits in length. The code 12345678
is perfectly valid. Now lets say the RFID tag sent
12345678execute-virus. The extra data "execute-virus" has to go
somewhere, and in some cases that "somewhere" might be a location of
memory that's currently pointed to by an instruction pointer.
Consequently that harmless extra "data" is magically transformed into
executable code, and executed.
Male Offspring of a female canine!!!
And coders have not caught on to this and fixed it after all this time?
Coders didn't even know the flaw existed. In the thousands of lines of
code it was a single blip that never showed on the radar. Or maybe they
did know it was there, but found it impossible to correct for at the time,
with the tools they had. Or maybe those tools themselves were the root
cause. Feces occurs...
*shrug*
That is another one that sounds pretty lame.
They knew the range of the data coming in.
The problem has existed and been identified for years.
But they can't limit the input at the time of input to truncate to
those ranges?

The language that they used was the problem?
Then use a different language.

This looks like a pretty simple problem.
They know what they are supposed to be getting as input, or range of
input.
But they can't trim or limit the input to that range?

Not buying that.
Sorry.
I never had that lack of ability in any of the software that I wrote in
all my years.
That is a simple thing to fix in all the stuff that I wrote.
Post by J. Francis
Post by CanopyCo
The laziness and incompetence of some modern coders is an embarrassment to
those of the old school who took pride in there work.
Now you're just flinging accusations from the position of "armchair
quarterback". If you honestly believe it's so trivial to produce bug free
code then by all means produce something of significance and show the rest
of the world how superior you are. ;)
All my software was bug free.
And it always did the job it was supposed to do, and nothing more.
I never said it was easy, just that a coder worth his pay did his job
instead of saying it was to hard to fix his bugs.
That's the lazy part I was talking about.
I always write it in small groups doing a set job, then keep running it
and fixing it until it did what it was told to do.
But then, I always used a programing language that had to be told to do
stuff, and only did what you told it to do.
Maybe these new guys should use a different language if they can't
control what it is doing.
Post by J. Francis
Post by CanopyCo
Post by J. Francis
If you were a coder you'd be singing a different tune entirely.
Well, it depends on what you call a coder. Have written for pay in
COBOL, RPGII, and various forms of BASIC for years.
But my software always aimed at data processing. Some called me a report
generator.
The coders I refer to are the people who write the software that make your
job possible. Not that report writing doesn't have its Coding aspects mind
you, but the tools you're allowed to use and the types of actions you're
allowed to perform don't lend themselves to self inflicted gunshot wounds
to the feet the way some other levels of coding does. IOW, your report
writing is irrelevant to the subject at hand.
Not really.
We are talking about a chip reader after all, not some fancy word
processor that runs macros and multiple fonts.

Exactly the type of work that I was doing.
Data input.
Data manipulated.
Data output.

Same old same old.

If they are making that job more dificult, then that it there falt, not
the falt of the job at hand.
Post by J. Francis
Post by CanopyCo
My software ran in the nature of;
Open file "data file" R
Read file #ID Number 8 digits, $name 25 digits, $address 25 digits. goto
do work
If anything was amis there, then you would get garbage on the screen.
Then you freely admit that you failed in your attempt to write perfect
software even as a report generator! Shame on you. Your "garbage on the
screen" is exactly the sort of failure that might be exploited by a crafty
attacker. Adjust input so that "garbage" becomes valid looking but
incorrect data, and presto... $10,000,000 in company funds accidentally
transfered to his anonymous bank account in the Cayman Islands.
The software would only do what it was doing in the first place.
It would tell the clerk to charge $ and reorder part number X.
Nothing more.
Now, a person can put a fake price tag on an item right now, but that
will not drain Walmart's bank account.
It would just get him that item at the wrong price.
Just like my software would do.
And if you put anything else on the tag, then the clerk would not see
anything it could use and go to get help.
If my program got XXXX's instead of $4.35, then it would display XXX in
the price field and the clerk would say "what the hell" and get help.
Still no money transferred to the Cayman Islands.

This is just a chip reader.
It is used to track items using a serial number and cross-referencing
that number to a known database.
Post by J. Francis
Post by CanopyCo
And anything to big would just be ignored.
And if you can't be aware of the precise size of all possible input when
you're writing your software? Like almost every programmer isn't?
Sure you can.
A chip reader is expecting a set sized input.
I always knew exactly what size my data input would be.
If you do not know what you are going to get as data in, then you
cannot know what you have when you get it.
Like, the first 8 digits are price, the next 23 digits are item number,
ect.
Add them all up and that is what you are getting.
Truncate all over that.
And the price is a number field, so limit that to only a number.

A JPG reader is also expecting a JPG.
That is why they won't read a MPG.
They are outside of the expected range.

And the program is working in a known area of memory, otherwise it
would never be able to find things that it was working with.
It knows where it put things.
Tell it to not put things outside its working range, into the range
that would allow that stuff to run.
It is known where the area is so that it will run.
Otherwise the virus guys would not know how big to make it to
"overflow" into the run area.
They know where it is, so maybe they should hire better programers to
tell them where that range is so that the JPG reader could be told to
not use that range, no matter what it read.
Post by J. Francis
*sigh*
Again, the example was an over simplified example for the sake of clarity.
The fact that you take them so literally while ignoring the real life
problems you should be aware of even as a report writer starts to make
your arguments look a little "uncommitted" to say the least. :(
We are talking about a chip reader here.
Data in (expected data at that, set to a known size)
Manipulate the data.
Data out.

It actually is that simple.
A bar code reader, that just used a chip instead of a bar code.
I coded for bar coder readers in BASIC at one time.

No need to make it more complicated then that at that point.
And if you are making it more complicated then it needs to be, then
that is the fault of the coder, not the job.
J. Francis
2006-03-21 05:00:01 UTC
Permalink
Post by CanopyCo
Frame Buffered mechanism?
Got no idea there, but do know that I could put any picture on a screen
that I wanted to by simply lighting up the correct series of pixels.
You're being childish. Obviously illuminating a light bulb can be
accomplished by flipping a switch, but that ignores the bulb's
manufacturer, then wires, the power company, the thousands of people who
work for them, the physics, and even the millions of years of chemistry
that produced the coal used to fire the generators.

Obviously there's a lot more to switching on a lamp than the switch, just
like there's a lot more to computer displays than turning on pixels. But
you apparently want nothing at all to do with reality.

The cold hard facts of the matter are that it certainly could be possible
for an RFID tag to spread malware, and that this has been empirically
demonstrated already in a controlled environment. Sorry about that, but
facts is as they say... facts.
Post by CanopyCo
Not trying to be a smart ass here.
None the less that is exactly what you're being. If you're truly so
oblivious to simple common sense and economics I apologize profusely, But
I suspect even you know your myopic argument is broken.
Post by CanopyCo
Just trying to understand where my perception is off enough that the
problem could not ever be prevented, no matter how hard you tried.
Mostly because you can not predict the future, or control outside
influences. There's no rational way to even say that you could
*imagine* every possible input or influence, let alone begin testing them
all.
Post by CanopyCo
Post by J. Francis
Yes, that's called data validation, bounds checking, and/or scrubbing
input. Coders have been wrestling with those things for decades now, yet
as programs grow in line count so do such errors. Often times they're
even inherited from other tools whose authors had no way of imagining
the ways their products would be used, and consequently no way of
testing for and dealing with a particular type of input.
One thing at a time.
No, you can't weasel dance around facts and common sense so easily. The
above paragraph answers to all your objections, save for the inanity of
simply discarding reality in favor of your "switch on a lamp" silliness.

Again the simple fact remains that it's impossible to account for every
possible scenario your code might encounter. Magnify that by the fact that
it's economically infeasible to write all the code for any significant
piece of software yourself, and multiply by the fact that a considerable
amount of credit for this problem belongs to the concept of digital
hardware itself, and you just begin to scratch the surface of a problem
that to be really honest isn't nearly as big as it could be simply BECAUSE
there's a lot of dedicated, brilliant people out there spending an awful
lot of time tracking down bugs and poor implementations of relatively bug
free code.
Post by CanopyCo
What other use are they putting JPG readers to other then reading JPG's?
Compression, encoding, interfacing to a graphics device through a GDI
or an OS thats completely out of your control and different on every
machine, handling all the bells and whistles like keeping track of the
user metadata people would wet themselves without, allocating and
deallocating memory for a working environment that's as dynamic as the
images themselves from a pool that's delivered differently on various
machines, validating the image itself, and garbage collecting all the
variables/literals/buffers you need to accomplish the above tasks and more.
Post by CanopyCo
Sounds like that would be really easy to fix, once one seen what they
To someone who thinks the switch and the bulb entail the whole of reality
I'd imagine it would seem trivial. That speaks more to your shortcomings
than it does to the ease or difficulty of writing bug free code.
Post by CanopyCo
Post by J. Francis
Again, you have an almost adolescent perception of what's involved in
authoring a piece of software. It simply is not as "easy" as you want
to suggest it is to support your argument. And if you believe it is so,
the I suggest you immediately "reform" the whole of the software
industry with your skill and wisdom. You would be made a very rich man
in deed. ;-)
I can't write that type of software, but that doesn't mean that I can't
see where looking at the problem in a simpler terms could be useful to
someone that can.
There's a line at which simple becomes completely out of touch with
reality. You crossed it two posts ago. :(

<snippage>
CanopyCo
2006-03-21 04:09:48 UTC
Permalink
A question just came to mind.
If it is impossible to fix the problem with JPG readers that has been a
problem ever sense Win 3, then why is it that Macintosh and LINUX
computers don't have that problem with there JPG readers?
Offbreed
2006-03-21 03:51:12 UTC
Permalink
Post by CanopyCo
A question just came to mind.
If it is impossible to fix the problem with JPG readers
It has been fixed, just as the previous one was fixed.

Until the next way to exploit is discovered <G>.

BTW, Win98 is immune to this one, and it's not real likely that the
writers are going to drop back to write a new exploit.

Do a search on "wmfpatch11.zip" for a test file.
CanopyCo
2006-03-22 16:21:51 UTC
Permalink
Post by Offbreed
Post by CanopyCo
A question just came to mind.
If it is impossible to fix the problem with JPG readers
It has been fixed, just as the previous one was fixed.
Until the next way to exploit is discovered <G>.
BTW, Win98 is immune to this one, and it's not real likely that the
writers are going to drop back to write a new exploit.
Do a search on "wmfpatch11.zip" for a test file.
Oh, ok.
So it is not exactly the same problem.
Just a similar one, done in a different way.

Now I am starting to get a grip on it.
Well, sort of.
Actually, starting to think that it is just outside of my ability to
completely understand, due to lack of information.

Kind of like brain surgery. ;-)

Ya, I know, I'm like a nail.
Got to pound on the head a while to get it flush. ;-)

Things were so much simpler back in the DOS days.
No way for anyone to mess up your work, other then actually stick a
disk in some PC, Considering that almost no one was on the net back
then..
:-/
J. Francis
2006-03-21 07:00:02 UTC
Permalink
Post by CanopyCo
A question just came to mind.
If it is impossible to fix the problem with JPG readers that has been a
problem ever sense Win 3, then why is it that Macintosh and LINUX
computers don't have that problem with there JPG readers?
1. It wasn't a problem with a "JPG readser", it was an operating system
issue. Or an issue with a piece of supporting code that was necessarily
installed with the OS install if you want to be a bit more precise. It
was also a problem that affected almost every Microsoft and third party
program that could display images.

2. It has been acceptably addressed.

3. The fact that a bug can be discovered and addressed has no bearing what
so ever on anyones ability to write bug free code, with the notable
exception that it's more empirical evidence that doing so is impossible
in the real world.

4. Other platforms and softwares have their own problems, some even caused
by "JPG readers".
CanopyCo
2006-03-22 16:36:10 UTC
Permalink
Post by J. Francis
3. The fact that a bug can be discovered and addressed has no bearing what
so ever on anyones ability to write bug free code, with the notable
exception that it's more empirical evidence that doing so is impossible
in the real world.
I think that we are talking about two different things when we say
"bug".

Bug, to me is when I use the incorrect syntax in coding my software and
it will not compile.
Bug, is also when I write a peace of software and it locks up while
setting there, like win 95 did before any patches were installed.
Bug, is also when I write a peace of software that is designed to put
out a report doing math, and the report shows incorrect math.

That is what I mean by "bug free".
It did not lock up just doing the job it was supposed to do, and it
gave the output that it was supposed to do.

I noticed in your other post that you are apparently getting frustrated
with me and therefore getting somewhat offensive.

That is not what I was trying to accomplish.
Maybe we should just set back and chill for a moment, before carrying
on.

When you are ready to continue, how about starting new on this thought.

You cannot get a virus from a bar code reader.
No bar code that I can enter will transfer money from Walmart to
anyplace.
So why not just make the chip reader operate in the same way a bar code
reader operates?

Both just input a set known serial number that is cross referenced to a
database.
CanopyCo
2006-03-22 19:09:38 UTC
Permalink
You know, something else just came to me.
We have been discussing these chips in a totally software outlook.
This totally disregards the hardware.

Let us say the chip and all the software is aimed at a 8 digit serial
number consisting of 1' and 0's.

Now, 4 binary digits give us 15 possible variations, and I am just to
lazy to go on calculating what 8 of them give, but I am sure it is a
bunch.

Regardless, let us presume that what ever amount that it is deemed that
we need, we have set the system to load that much + 4 more binary
digits.
This would give us lots of growing room.

For this example, we will call that number 8.

Now then, we start with the scanner.
It is hardware, and scans the chip, just like it would scan a bar code,
using hardware to read the signal and store the information so that the
software can access it.

That hardware is, at one point, a memory chip that has 8 digits.
That is what the chip holds.
8 possible 1's or 0's.
They are cheep, far cheeper then the bigger memory modules, and is all
that is needed in that little hand scanner that is scanning the chip.

It will not matter how many digits the scanner reads, the memory chip
will only retain the first 8 digits that it receives.
Then the software will read those 8 digits and reset the chip.

So, how is a virus going to get past that hardware?
No buffer over run possible, due to the chip only holding the 8
expected digits and automatically truncating the input down to that 8
digits.

And no reason to make it fancier then that, sense that is the cheapest
method to do that job, and is the way it has been done for many years.

At that point, the hardware is sending a number.
Just a number.
That is all.
And the software is designed to receive a number consisting of 8 binary
bits.
And it is designed to manipulate that number as a number.
That is all.
Just like when you type a number into a calculator.
No matter what number you type into that calculator, it will not format
your hard drive.
It may produce an error for to many digits, but it will never send all
your money to Spain.
It takes that number and looks up that number in a preexisting
database.
At that point, it does the commands associated with that number, based
on the commands that are in the database.

Nothing that you put in that chip will do anything that is not already
determined by command # so and so, listed in a preexisting database.
And no number that you enter into that database will change it or
rewrite it.

No virus damage possible.
The only damage possible is if a command already contained in the
database is issued when it is not desired.

Sure, you can change the price of something.
Just like you can by switching the stickers now.
But all you will be able to do is what you can do now by changing a
item number.
You will effect inventory and show something out that is not out.
You will possibley trigger automatic reordering of that product.
But you will not transfer all of Walmart's credit card records into
your e-mail, nor transfer all there money into your account.
J. Francis
2006-03-22 20:00:02 UTC
Permalink
Post by J. Francis
3. The fact that a bug can be discovered and addressed has no bearing
what so ever on anyones ability to write bug free code, with the notable
exception that it's more empirical evidence that doing so is impossible
in the real world.
I think that we are talking about two different things when we say "bug".
Your perception of the term "bug" is every bit as broken as your
perceptions of what it means to write consumer software. I'm not trying to
be a prick either, it's just a fact. Sorry.
Bug, is also when I write a peace of software and it locks up while
setting there, like win 95 did before any patches were installed. Bug, is
Windows 95 never "locked up while sitting there". No operating system will
execute any function at rest, and if nothing is being done it will not
change states from "sitting there" to "locked up". Those unexplained
lockups have definable causes. They're errors in some process that you
simply aren't aware of.

Again your drastically over simplified view of reality has lead you to a
completely erroneous presumption.
also when I write a peace of software that is designed to put out a
report doing math, and the report shows incorrect math.
I thought you claimed you *never* made a mistake...?

Oooops... :)
I noticed in your other post that you are apparently getting frustrated
with me and therefore getting somewhat offensive.
You're being obtuse and childish. I have a low tolerance for any of it.
Fact is, I restrained myself considerably because I believe that YOU
believe you're trying to solve some debate.

You're not. Your perceptions are so utterly FUBAR you're quite honestly
just making yourself look foolish. As I stated in another post you're
arguing that flipping the light switch is all that is involved with
illuminating your desk lamp. Obviously that's a simplistic, adolescent
description of the processes that are involved.
That is not what I was trying to accomplish. Maybe we should just set
back and chill for a moment, before carrying on.
Don't worry, if I get really frustrated or believe you're doing nothing
but playing troll games you'll know it. I'm chillin'... trust me. ;)
When you are ready to continue, how about starting new on this thought.
You cannot get a virus from a bar code reader. No bar code that I can
Totally irrelevant. Like saying a glass won't hold water because you can't
carry the stuff in a sieve.

Oh, and by the way, several methods for including unwanted or clandestine
information within bar codes have already been developed and implemented.
And bar codes have been exploited for nefarious purposes. So it's not
completely beyond the stretches of imagination that malware could be
encoded in bar sequences. If a suitable bug in the firmware running the
bar code readers is discovered, anything is possible.

The issue is moot in any case. We know for a fact that it *is* possible to
transmit BadThings(tm) from an RFID tag to the back end software because
it's already been done, at least in a laboratory environment.
enter will transfer money from Walmart to anyplace. So why not just make
the chip reader operate in the same way a bar code reader operates?
Both just input a set known serial number that is cross referenced to a
database.
No, that's not just what either of them do. Again you're over simplifying
a process to the point at which your argument crosses the line between
simplified, and unequivocally ridiculous.

One last time I'll outline the underlying principals for you...

Memory in a "digital" machine is allocated and accessed in segments. It's
a hardware limitation, impossible to circumvent completely. For that
matter, even completely analog processes have bounds and limits that can
be breached. It's really a limitation of the physical world, in a sorta
Zen-like way.

Software is forced to function within the above constraints. It's forced
to allocate not only storage space in "chunks", but also the areas of
memory used for storing executable instructions. They're allocated and
used in well known and predictable ways, mostly out of necessity because
of the above hardware limitations. It's the principal of deterministic
machines always producing the same result for the same effect. Simplified,
it's become the age old "garbage in, garbage out" slogan.

If you try to pour 13 ounces of water in a 12 ounce glass you will have
watter laying at a low point, somewhere outside the glass. If you're doing
your water pouring job like a smart little Gunga Din, you have a towel or
napkin handy to sop up the excess. Of course if some miscreant turns the
fire hose on you and your water pouring venture your towel is meaningless
and you, are proverbially screwed. That miscreant has demolished every bit
of your well planned excess water safety measures, and you, because you're
a mythical character out in some imaginary desert, didn't even know fire
hoses existed. Then it starts to rain... and you get the memo about the
glass manufacturer using Avoirdupois ounces and you were told Troy... :(

And that, my friend, is the reason your Utopia is a pipe dream and your
arguments are just silly. Programmers are first dealing with a system
that's fundamentally vulnerable. They're then facing the task of making
that system conform and behave in an environment where it's physically
impossible to know of or predict every fire hose or rain storm, using
tools that may or may not themselves be flawed. That is the *reality* of
software design, simplified as it *should* be, not as you wish it could be.
Tim May
2006-03-22 20:18:07 UTC
Permalink
Post by J. Francis
Post by CanopyCo
Bug, is also when I write a peace of software and it locks up while
setting there, like win 95 did before any patches were installed. Bug, is
Windows 95 never "locked up while sitting there". No operating system will
execute any function at rest, and if nothing is being done it will not
change states from "sitting there" to "locked up". Those unexplained
lockups have definable causes. They're errors in some process that you
simply aren't aware of.
I worked on a problem where many kinds of systems _did_ just "lock up
while sitting there." Last I googled, the problem is still out there,
seen notably on large Sun Microsystems servers.

(Related to cosmic rays and low-level ionizing radiation.)

At the time, people could not conceive of how a system could "just sit
there," and yet have a lock-up.


--Tim May
Post by J. Francis
Again your drastically over simplified view of reality has lead you to a
completely erroneous presumption.
Post by CanopyCo
also when I write a peace of software that is designed to put out a
report doing math, and the report shows incorrect math.
I thought you claimed you *never* made a mistake...?
Oooops... :)
Post by CanopyCo
I noticed in your other post that you are apparently getting frustrated
with me and therefore getting somewhat offensive.
You're being obtuse and childish. I have a low tolerance for any of it.
Fact is, I restrained myself considerably because I believe that YOU
believe you're trying to solve some debate.
You're not. Your perceptions are so utterly FUBAR you're quite honestly
just making yourself look foolish. As I stated in another post you're
arguing that flipping the light switch is all that is involved with
illuminating your desk lamp. Obviously that's a simplistic, adolescent
description of the processes that are involved.
Post by CanopyCo
That is not what I was trying to accomplish. Maybe we should just set
back and chill for a moment, before carrying on.
Don't worry, if I get really frustrated or believe you're doing nothing
but playing troll games you'll know it. I'm chillin'... trust me. ;)
Post by CanopyCo
When you are ready to continue, how about starting new on this thought.
You cannot get a virus from a bar code reader. No bar code that I can
Totally irrelevant. Like saying a glass won't hold water because you can't
carry the stuff in a sieve.
Oh, and by the way, several methods for including unwanted or clandestine
information within bar codes have already been developed and implemented.
And bar codes have been exploited for nefarious purposes. So it's not
completely beyond the stretches of imagination that malware could be
encoded in bar sequences. If a suitable bug in the firmware running the
bar code readers is discovered, anything is possible.
The issue is moot in any case. We know for a fact that it *is* possible to
transmit BadThings(tm) from an RFID tag to the back end software because
it's already been done, at least in a laboratory environment.
Post by CanopyCo
enter will transfer money from Walmart to anyplace. So why not just make
the chip reader operate in the same way a bar code reader operates?
Both just input a set known serial number that is cross referenced to a
database.
No, that's not just what either of them do. Again you're over simplifying
a process to the point at which your argument crosses the line between
simplified, and unequivocally ridiculous.
One last time I'll outline the underlying principals for you...
Memory in a "digital" machine is allocated and accessed in segments. It's
a hardware limitation, impossible to circumvent completely. For that
matter, even completely analog processes have bounds and limits that can
be breached. It's really a limitation of the physical world, in a sorta
Zen-like way.
Software is forced to function within the above constraints. It's forced
to allocate not only storage space in "chunks", but also the areas of
memory used for storing executable instructions. They're allocated and
used in well known and predictable ways, mostly out of necessity because
of the above hardware limitations. It's the principal of deterministic
machines always producing the same result for the same effect. Simplified,
it's become the age old "garbage in, garbage out" slogan.
If you try to pour 13 ounces of water in a 12 ounce glass you will have
watter laying at a low point, somewhere outside the glass. If you're doing
your water pouring job like a smart little Gunga Din, you have a towel or
napkin handy to sop up the excess. Of course if some miscreant turns the
fire hose on you and your water pouring venture your towel is meaningless
and you, are proverbially screwed. That miscreant has demolished every bit
of your well planned excess water safety measures, and you, because you're
a mythical character out in some imaginary desert, didn't even know fire
hoses existed. Then it starts to rain... and you get the memo about the
glass manufacturer using Avoirdupois ounces and you were told Troy... :(
And that, my friend, is the reason your Utopia is a pipe dream and your
arguments are just silly. Programmers are first dealing with a system
that's fundamentally vulnerable. They're then facing the task of making
that system conform and behave in an environment where it's physically
impossible to know of or predict every fire hose or rain storm, using
tools that may or may not themselves be flawed. That is the *reality* of
software design, simplified as it *should* be, not as you wish it could be.
CanopyCo
2006-03-23 01:02:37 UTC
Permalink
Post by J. Francis
Post by J. Francis
3. The fact that a bug can be discovered and addressed has no bearing
what so ever on anyones ability to write bug free code, with the notable
exception that it's more empirical evidence that doing so is impossible
in the real world.
I think that we are talking about two different things when we say "bug".
Your perception of the term "bug" is every bit as broken as your
perceptions of what it means to write consumer software. I'm not trying to
be a prick either, it's just a fact. Sorry.
Just using the definition that was taught to me by my COBOL instructor
back in the 80's.
It may have changed, but that in no way changes the meaning back when I
learned it, nor the meaning that I had when I used it.

What I described is what I was talking about.

If you were talking abut something different, then we had a
communication problem.
Post by J. Francis
Bug, is also when I write a peace of software and it locks up while
setting there, like win 95 did before any patches were installed. Bug, is
Windows 95 never "locked up while sitting there". No operating system will
execute any function at rest, and if nothing is being done it will not
change states from "sitting there" to "locked up". Those unexplained
lockups have definable causes. They're errors in some process that you
simply aren't aware of.
Those errors are obvious.
One of them is that the PC will not take any inputs at all.
And those errors were due to the software writer not doing his job
correctly and getting all of what I call bugs out of his software.
They were not due to viruses, or any other software running on the PC.
They were inherent in the Win 95 edition 1 software.
I know this from tests that I ran using various PC that did nothing but
set there with nothing on them that did not come on the Win 95 disk.
Post by J. Francis
Again your drastically over simplified view of reality has lead you to a
completely erroneous presumption.
Ok, look here, "lock up", to anyone but you, means that when I push a
button or move the mouse, nothing happens.
No matter how long I wate, or what buttens I push, I can not get any
use out of my PC untill I reboot it.
And win 95 edition 1 did lock up quite regulairly.
I was selling PC at that time, and sold quite a few coppies of win 3.11
and DOS 6.22 becouse they came back complaining about just exactly
that.

If you do not know what "locked up" means, then your abilities are
definitly is question.

You ever do any customer support?
If so, how, when you do not know what "locked up" means?
Post by J. Francis
also when I write a peace of software that is designed to put out a
report doing math, and the report shows incorrect math.
I thought you claimed you *never* made a mistake...?
Oooops... :)
I clamed that I never let a peace of software get to the costumer phase
with a mistake in it.
I never clamed that everything I wrote compiled correctly the first
time.
I also said that I kept at a peace of software until I got it right,
instead of selling it and claiming that it was impossible to fix it.

:-p
:-)
Post by J. Francis
I noticed in your other post that you are apparently getting frustrated
with me and therefore getting somewhat offensive.
You're being obtuse and childish. I have a low tolerance for any of it.
Fact is, I restrained myself considerably because I believe that YOU
believe you're trying to solve some debate.
Basically, yes, I am trying to understand how things have changed from
the 80's when I wrote software to now, in such a manner that it is now
impossible to make things as dependable as they once were.

Your inability to teach is in no way an indication of my inability to
learn.

You simply have no intention of teaching.
Just insulting.
Post by J. Francis
You're not. Your perceptions are so utterly FUBAR you're quite honestly
just making yourself look foolish. As I stated in another post you're
arguing that flipping the light switch is all that is involved with
illuminating your desk lamp. Obviously that's a simplistic, adolescent
description of the processes that are involved.
Your entirely missing my point.
I can make a picture on my screen by flipping a light switch.
You may be doing things in a much more difficult manner.
And that may be required now.
But that did not change the fact that I can make that picture by
flipping those switches.
And that is how I did it, when I was doing it.

It appears that this methods is no longer used.
But you act as if it has never been used, and would never work.

Do you know nothing of the poke or peek commands?
If not, then your software experience is somewhat questionable, or at
least limited.

I wonder if you have ever used DOS or punch cards either.
Post by J. Francis
That is not what I was trying to accomplish. Maybe we should just set
back and chill for a moment, before carrying on.
Don't worry, if I get really frustrated or believe you're doing nothing
but playing troll games you'll know it. I'm chillin'... trust me. ;)
I'm defiantly not trying to play games with you.

And I am willing to concede that for reasons not completely understood
by me, JPG editors are subject to a weakness that is being attacked in
different ways. And that is how viruses are effecting JPG editors,
while appearing to be the same problem.
It is the same weakness, but attacked in a different way, making a
different problem.

Is this basically correct?
Post by J. Francis
When you are ready to continue, how about starting new on this thought.
You cannot get a virus from a bar code reader. No bar code that I can
Totally irrelevant. Like saying a glass won't hold water because you can't
carry the stuff in a sieve.
Oh, and by the way, several methods for including unwanted or clandestine
information within bar codes have already been developed and implemented.
And bar codes have been exploited for nefarious purposes. So it's not
completely beyond the stretches of imagination that malware could be
encoded in bar sequences. If a suitable bug in the firmware running the
bar code readers is discovered, anything is possible.
The issue is moot in any case. We know for a fact that it *is* possible to
transmit BadThings(tm) from an RFID tag to the back end software because
it's already been done, at least in a laboratory environment.
What are they doing, using a serial or parallel port to access the
input form the bar code readers now days instead of the reader having
its own memory chip?
Post by J. Francis
enter will transfer money from Walmart to anyplace. So why not just make
the chip reader operate in the same way a bar code reader operates?
Both just input a set known serial number that is cross referenced to a
database.
No, that's not just what either of them do. Again you're over simplifying
a process to the point at which your argument crosses the line between
simplified, and unequivocally ridiculous.
One last time I'll outline the underlying principals for you...
Memory in a "digital" machine is allocated and accessed in segments. It's
a hardware limitation, impossible to circumvent completely. For that
matter, even completely analog processes have bounds and limits that can
be breached. It's really a limitation of the physical world, in a sorta
Zen-like way.
Exactly that limitation is what I am looking at.
The input from the bar code reader comes from the reader.
It likely comes in as a parallel input, sense the bar code is read as a
single line.
Post by J. Francis
From a RFID chip it would likely come in as a serial input.
Now, if the reader had its own memory chip that captured and stored
that information until the software took the information and then reset
the chip, it would be immune to any form of bad ware input.
Due to the memory chip only holding the expected amount of digits.
And they would still only be 1's and 0's.

Sniped the rest of this, as it did not address how a virus got past the
memory chip in the hand scanner that only held the number of digits
that it expected.

And as to overload from to much coming from the RFID chip, that can be
addressed this way.

The hand scanner sends out a signal, we will call it "give me the
data".
At that point it starts receiving the data, likely in serial sense it
is a radio signal, and starts loading it into its memory chip.
Now, once that chip is full, it stops taking input.
That is done with hardware.
It has a counter, and counts the number of inputs.
When it get the right number of inputs, it quits taking input.
Doesn't matter if more is coming, because it's memory chip is full and
it has stopped taking input.

Now you have a simple number.
It is the right size.
And it is handled as nothing more then a serial number.
If it did not match any serial numbers in the database, then it is
rejected as an incorrect input error right there at the scanner /
database interface.

If this is not what they are doing, then why?
After all, this would solve this problem with little difference in cost.
J. Francis
2006-03-23 07:15:02 UTC
Permalink
Post by CanopyCo
Post by J. Francis
I think that we are talking about two different things when we say "bug".
Your perception of the term "bug" is every bit as broken as your
perceptions of what it means to write consumer software. I'm not trying
to be a prick either, it's just a fact. Sorry.
Just using the definition that was taught to me by my COBOL instructor
back in the 80's.
Back in the 80's what you described was in fact the bulk of what COBOL
programmers would have encountered as "bugs". Dennis Ritchie and his
followers would have had a completely different view of things, even
then. A quarter of a century later and a lifetime of programming paradigms
away, the examples have expanded to include a considerable number of more
"modern" mishaps.

The fact that your perceptions have been broken by time doesn't make them
any less broken. Any unintended behavior in any sort of code (or even most
hardware and firmware for that matter) can be described as a "bug". A
vulnerability is, in general terms, a type of bug that facilitates some
sort of undesirable or unplanned control over a system.
Post by CanopyCo
Post by J. Francis
Windows 95 never "locked up while sitting there". No operating system
will execute any function at rest, and if nothing is being done it will
not change states from "sitting there" to "locked up". Those
unexplained lockups have definable causes. They're errors in some
process that you simply aren't aware of.
Those errors are obvious.
One of them is that the PC will not take any inputs at all. And those
Yes, and that sort of behavior isn't the result of an operating system
that locks up "just sitting there". It may *appear* to you to be doing
nothing, but behind the scenes it's still processing data, lighting those
pixels you're so fond of, allocating and deallocating memory, ticking
off time, writing/reading storage space and memory locations, etc...
etc... etc...

Ironically enough, most unexplained "lockups when the computer's just
sitting there" can be attributed to graphics/GDI problems. Yes, that
simple "lighting of pixels". It's one of the most bug prone facets of
modern PC's. Those lockups that can't be traced to display issues are most
frequently hardware and "heat" problems.
Post by CanopyCo
errors were due to the software writer not doing his job correctly and
getting all of what I call bugs out of his software. They were not due
An impossible goal. The concept of completely bug free code is a pipe
dream. Wishful thinking. It's simply not humanly or physically possible
given any significant piece of programming. And if you would happen to
come close, the display drivers on one machine running your code could
walk all over it, and on another it might encounter an odd BIOS
incompatibility because it's so "rigid" it can't deal with some screwy
environment issue that translates drive geometry in one of the 10 billion
ways you didn't think of.
Post by CanopyCo
to viruses, or any other software running on the PC. They were inherent
in the Win 95 edition 1 software. I know this from tests that I ran
using various PC that did nothing but set there with nothing on them
that did not come on the Win 95 disk.
That's completely irrelevant. That certain versions of a software have
their own "quirks" is given. What you're failing to understand is that
those problem have causes, and those causes are usually called... bugs.
Post by CanopyCo
Post by J. Francis
Again your drastically over simplified view of reality has lead you to
a completely erroneous presumption.
Ok, look here, "lock up", to anyone but you, means that when I push a
button or move the mouse, nothing happens. No matter how long I wate, or
what buttens I push, I can not get any use out of my PC untill I reboot
it.
That's the effect, not the cause. That's what you see, not what made it
happen.
Post by CanopyCo
And win 95 edition 1 did lock up quite regulairly. I was selling PC at
that time, and sold quite a few coppies of win 3.11 and DOS 6.22 becouse
they came back complaining about just exactly that.
I remember the era well myself. Doing the exact same thing. Downgrading an
entire law firm in fact, after their "experiment" with early versions of
95 caused them so many problems.

What can I say... I tried to warn them off being on the bleeding edge but
Boss Suit was a self proclaimed technophile. The invoice reflected my
dissatisfaction with his denial that I knew best, as well the weekend it
took me to rebuild all their workstations behind his self imposed
"upgrade". Fortunately, God and I favored them by having designed their
network around NT servers, centralized data storage, and overly
cautious backup routines. ;-)
Post by CanopyCo
If you do not know what "locked up" means, then your abilities are
definitly is question.
I'll match my ability and experience against yours ANY day.
Post by CanopyCo
You ever do any customer support?
Geee lemme think.... I designed and built the county wide library network
in my home state, built and sold the hardware and maintained the network
at the local courthouse law library and Judge's chambers, built/supported
a considerable amount of hardware for three area hospitals, Built and
administered the network for a moderate sized international law firm,
built and administered the network for a large medical support group
comprised of about a dozen area physicians and their staff, built,
supported, and trained all the employees in the use of the new equipment
and software at a printing house that produced a bi-weekly "shiny sheet"
type newspaper (among other things), built and supported standalone
machines and small "networks" to probably thousands of people and
businesses over the course of the almost two decades I was in that
business, sold my services as nothing *but* a trainer and consultant to
many hundreds more, and even built some of the equipment and consulted on
my home town's first public ISP, then sold accounts and supported it from
the storefront I worked.

Support? *laugh* I could solve problems over the phone in my head by
visualizing the Windows menus and configuration screens while was
troubleshooting a CAD machine for a local machine shop and hammering
together a new machine for the hospital. Which at one time I could do in
less than 9 minutes from a pile of parts to an assembled box happily
accepting its operating system. :)

I spent 8 years coding 65c02 ASM language for embedded medical equipment
applications, where code quality was absolutely critical and examined by
government auditors on a regular basis. I coded a couple rather less than
significant utilities for BBS SysOps in C ages ago, and wrote a couple
"Door" games that became quite popular on the select BBS's I donated them
to. In fact my first experience with "grownup" coding issues inherited
from others was with the TriDoor library. I've designed and built a number
of significant commercial web sites from the ground up, including a custom
shopping cart written from scratch with a PHP front end and a back end in
Python (I love Python). I have (checking...) 17,921 lines of custom code
on this machine alone that I'm using or have used just as "problem
solving" crap for my own purposes, and I'm currently involved in a
collective coding project relating to, imagine this... computer security
and user privacy.

And that's just the fraction of my more or less professional experience I
recalled off the top of my head for your benefit. My resume is
considerably more impressive than that. On the civilian side I also ran a
BBS for a good number of years and dealt with all those questions. I
hosted/ran one computer user group and participated as a "guru" in
another. Presently I'm semi-retired building and selling Linux boxes
basically at cost to retirees and shut-ins in my area, and training them
on how to use their nicely customized, secure, and stable machines to see
those pictures of the grandkids.

IOW, I'm that "computer guy" with the brain everyone always wants to
pick, and it's been that way for a very, very long time...
Post by CanopyCo
If so, how, when you do not know what "locked up" means?
I know exactly what you're talking about. You're confused about why they
happen. I'm anything but.
Post by CanopyCo
Post by J. Francis
also when I write a peace of software that is designed to put out a
report doing math, and the report shows incorrect math.
I thought you claimed you *never* made a mistake...?
Oooops... :)
I clamed that I never let a peace of software get to the costumer phase
with a mistake in it.
That you're aware of or will admit to anyway. ;)
Post by CanopyCo
I never clamed that everything I wrote compiled correctly the first
Compiling without errors and running perfectly under every condition in
every scenario are two completely different animals. To be brutally
honest, the sort of programming you're talking about is so limited in
scope that the chances of you making less than obvious mistakes were nil.
Still, I'm surprised that you weren't aware of, and use to working around
the bugs that I remember popping up from time to time in various COBOL
compilers.
Post by CanopyCo
time. I also said that I kept at a peace of software until I got it
right, instead of selling it and claiming that it was impossible to fix
it.
You're being obtuse and childish again. I never said it was impossible to
fix an error, I said errors would occur. And that outside the realm of
trivial coding tasks it's humanly impossible to account for every
eventuality or scenario.
Post by CanopyCo
Post by J. Francis
Fact is, I restrained myself considerably because I believe that YOU
believe you're trying to solve some debate.
Basically, yes, I am trying to understand how things have changed from
the 80's when I wrote software to now, in such a manner that it is now
impossible to make things as dependable as they once were.
Nothing has changed. And after the wash out your perceptions were as
incorrect then as they are now. The only thing that's really changed is
the sheer size of the problem.
Post by CanopyCo
Your inability to teach is in no way an indication of my inability to
learn.
Abilities have zero to do with it, you're aggressively fighting the
lesson... *shrug*
Post by CanopyCo
You simply have no intention of teaching. Just insulting.
I'm just stating facts. You apparently have absolutely no interest in even
the things that common sense should tell you without any help for anyone
at all. The "pixels on a screen" idiocy is a prime example. I've explained
to you now a couple times that it's a tad more involved than that, but you
keep singing the same old song like you never read a word of it. You're
actively avoiding even trying to learn anything from where I sit.
Combatively discarding what you dislike, and parroting your thread bare
misconceptions in spite of the compelling evidence that's right in front
of your face.
Post by CanopyCo
Your entirely missing my point.
I can make a picture on my screen by flipping a light switch. You may be
doing things in a much more difficult manner.
It's you, sir, that's entirely missing the point. You and I do exactly
the same thing when we "make a picture on our screens", but you only see
the flipping switch and I'm aware of how it all works. The fact that you
won't or can't comprehend what's going on doesn't make any of it any less
real any more than believing the Sun revolved around the Earth because it
came up over the horizon made planetary orbits cease to exist.
Post by CanopyCo
And that may be required
now.
But that did not change the fact that I can make that picture by
flipping those switches.
And that is how I did it, when I was doing it.
No, you did not. I've explained the essentials to you with easy analogy
several times now, and you willfully refuse to hear any of it. Even back
when I cut my teeth programming machines by loading registers with
*ACTUAL* switches that's not all that was going on.
Post by CanopyCo
It appears that this methods is no longer used. But you act as if it has
never been used, and would never work.
I've said nothing of the sort. Nothing like that at all. It worked, and
still works just fine. Other things work too. But they're ALL susceptible
to the limitations of space and time, and human nature. As long as there
has been coding and computers there have been bugs, and as long as they
remain, there *will be* bugs.
Post by CanopyCo
Do you know nothing of the poke or peek commands? If not, then your
software experience is somewhat questionable, or at least limited.
I not only know them, I can recognize them in machine language, two levels
underneath the pretty user interface that shielded you from knowing what
you were really doing when you typed your friendly BASIC commands. While
you were stringing together GOTO-PRINT-RUN, I was hacking machine code and
burning a custom BIOS for the computer I cobbled together from spare
parts and an old portable TV. And "debugging" with an oscilloscope. I
still have that computer in in storage in fact, complete with the custom
BASIC interpreter I wrote just so I could amuse myself with a program
that took lists of my friend's names, objects, and verbs, and strung them
together in amusing random sentences.
Post by CanopyCo
Post by J. Francis
Don't worry, if I get really frustrated or believe you're doing nothing
but playing troll games you'll know it. I'm chillin'... trust me. ;)
I'm defiantly not trying to play games with you.
And I am willing to concede that for reasons not completely understood
by me, JPG editors are subject to a weakness that is being attacked in
different ways. And that is how viruses are effecting JPG editors, while
appearing to be the same problem. It is the same weakness, but attacked
in a different way, making a different problem.
Is this basically correct?
Absolutely not.

First of all, we're not talking about a "JPG editor", we're talking about
myriads of programs that handle even more types of graphics files.

Second, the exact bug we were talking about earlier had nothing to do
with any specific "JPG editor", it was a flaw in what essentially boils
down to the operating system, that was "inherited" by various other
programs like web browsers, spread sheets, word processors, and yes...
even "JPG editors".

Third, there is by no wild stretch of the imagination what you could call
even a small number of bugs that have been discovered in programs that, in
essence, only manipulate pretty pictures. They can generally be classified
into a small number of general types, but the individual bugs probably
number in the many thousands if you travel back through history. Some
are severe, some are minor, they all have their roots in some fairly basic
and undeniable principles, and they're all as different as the individual
coder who wrote them and the unpredictable machines that run said code.
Post by CanopyCo
Post by J. Francis
Oh, and by the way, several methods for including unwanted or
clandestine information within bar codes have already been developed
and implemented. And bar codes have been exploited for nefarious
purposes. So it's not completely beyond the stretches of imagination
that malware could be encoded in bar sequences. If a suitable bug in
the firmware running the bar code readers is discovered, anything is
possible.
[...]
Post by CanopyCo
What are they doing, using a serial or parallel port to access the input
form the bar code readers now days instead of the reader having its own
memory chip?
What "memory chip"? You're reading information, and you have to do
something with it. That by *definition* means processor and at least
firmware. Whether it resides in the reader or externally is irrelevant. If
you're scrubbing data in the reader there's a processor there. If not,
it's passing the "whatever" it's reading.

Typically the wand itself is a "dumb" device that interfaces to a
terminal. The "cash register". That cash register runs <gasp> Point of
Sale software. That device in turn is almost always wired to some sort of
inventory control infrastructure back behind the swinging doors beside the
customer restrooms... or maybe even in a different state.
Post by CanopyCo
Post by J. Francis
Memory in a "digital" machine is allocated and accessed in segments.
It's a hardware limitation, impossible to circumvent completely. For
that matter, even completely analog processes have bounds and limits
that can be breached. It's really a limitation of the physical world,
in a sorta Zen-like way.
Exactly that limitation is what I am looking at. The input from the bar
code reader comes from the reader. It likely comes in as a parallel
input, sense the bar code is read as a single line.
Those readers are almost always serial devices in my experience, but
my experience is trivial and it's completely irrelevant in any case. The
shape of the data isn't important, the variability is.
Post by CanopyCo
From a RFID chip it would likely come in as a serial input.
No, actually it's a pulse modulated signal with data being read off the
trailing edge of the pulses. A series of signals are generated and the tag
"echos" in a certain way depending on what data it holds.
Post by CanopyCo
Now, if the reader had its own memory chip that captured and stored that
information until the software took the information and then reset the
chip, it would be immune to any form of bad ware input.
Irrelevant. At some point software picks up the data and the fun begins.
Post by CanopyCo
Due to the
memory chip only holding the expected amount of digits. And they would
still only be 1's and 0's.
It's *ALL* only 1's and 0's. The data, the software diddling it, the drive
controller firmware on the storage device that archives your address for
future junk mailings... *ALL* of it.
Post by CanopyCo
And as to overload from to much coming from the RFID chip, that can be
addressed this way.
The hand scanner sends out a signal, we will call it "give me the data".
At that point it starts receiving the data, likely in serial sense it is
a radio signal, and starts loading it into its memory chip. Now, once
that chip is full, it stops taking input. That is done with hardware. It
has a counter, and counts the number of inputs. When it get the right
number of inputs, it quits taking input. Doesn't matter if more is
coming, because it's memory chip is full and it has stopped taking
input.
That's essentially how it works *now* with a few exceptions, and it's been
proved vulnerable. The problem isn't taking a specific size of data off
the tag, it's processing that information. Your "preprocessing" theory is
fundamentally flawed because the data isn't consistent in length or
segmentation. You're describing a scenario that simply does not exist in
the real world. Sorry.
Post by CanopyCo
Now you have a simple number.
It is the right size.
And it is handled as nothing more then a serial number. If it did not
Not possible. That would make RFID tags utterly useless. I believe at
current most RFID tags carry 128K of memory space. In that space you will
find APC, dates, manufacturer and retail location information, and
probably a lot of other garbage. It's all necessary for things like
letting you trundle through the exit with your new DVD copy of your
favorite movie without setting off the alarm, while still triggering that
same alarm when the guy right behind you tries to leave with the copy
of the exact same movie he shoved down his pants.

And *that's* just your local shopping mall RFID tag.

Don't forget they have medical and law enforcement applications too,
including things like having codes for your allergies and heart attack
history available for immediate retrieval, and contact information for a
lost pet's owner.

Again you've run into that over simplification wall head on. It's
obviously impossible to treat data stored on an RFID tag as "a simple
number". Fact is, it's cost prohibitive to design them in such a way that
they can only store a certain amount of numbers of a certain size, because
customer "A" will have different data requirements than customer "B". That
means leaving all 128K open for "flat" R/W and dealing with data field
sizes and quantities in software.
Gunner
2006-03-23 10:39:59 UTC
Permalink
Post by J. Francis
Post by CanopyCo
back in the 80's.
Back in the 80's what you described was in fact the bulk of what COBOL
programmers would have encountered as "bugs".
today..they are called undocumented features.....

Gunner


"The importance of morality is that people behave themselves even if
nobody's watching. There are not enough cops and laws to replace
personal morality as a means to produce a civilized society. Indeed,
the police and criminal justice system are the last desperate line of
defense for a civilized society. Unfortunately, too many of us see
police, laws and the criminal justice system as society's first line
of defense." --Walter Williams
CanopyCo
2006-03-23 18:44:13 UTC
Permalink
Post by J. Francis
Post by CanopyCo
Post by J. Francis
I think that we are talking about two different things when we say "bug".
Your perception of the term "bug" is every bit as broken as your
perceptions of what it means to write consumer software. I'm not trying
to be a prick either, it's just a fact. Sorry.
Just using the definition that was taught to me by my COBOL instructor
back in the 80's.
Back in the 80's what you described was in fact the bulk of what COBOL
programmers would have encountered as "bugs". Dennis Ritchie and his
followers would have had a completely different view of things, even
then. A quarter of a century later and a lifetime of programming paradigms
away, the examples have expanded to include a considerable number of more
"modern" mishaps.
The fact that your perceptions have been broken by time doesn't make them
any less broken. Any unintended behavior in any sort of code (or even most
hardware and firmware for that matter) can be described as a "bug". A
vulnerability is, in general terms, a type of bug that facilitates some
sort of undesirable or unplanned control over a system.
It appears your communication skills are as broken as my using 80's
definitions when talking to a 06 person. ;-)

I get the bases of our communication problem now.
For me, now and always, when I say "bug" I mean that it was a coding
error.
When I say "vulnerability", I mean that it is capable of being forked
up by some jackass doing something that they were not supposed to just
trying to fork things up. That can be anything from dumping coffee down
the vent to writing malware.

Were on the same page now.
Sorry for my part in us not getting there sooner.

I can easily see where vulnerabilities would be difficult if not
impossible to totally do away with.

Microsoft's coding errors, other wise known as random features, however
are an entirely different matter.
And that is what started my thoughts down the trail that I tool.
Post by J. Francis
Post by CanopyCo
Post by J. Francis
Windows 95 never "locked up while sitting there". No operating system
will execute any function at rest, and if nothing is being done it will
not change states from "sitting there" to "locked up". Those
unexplained lockups have definable causes. They're errors in some
process that you simply aren't aware of.
Those errors are obvious.
One of them is that the PC will not take any inputs at all. And those
Yes, and that sort of behavior isn't the result of an operating system
that locks up "just sitting there". It may *appear* to you to be doing
nothing, but behind the scenes it's still processing data, lighting those
pixels you're so fond of, allocating and deallocating memory, ticking
off time, writing/reading storage space and memory locations, etc...
etc... etc...
Actually, I did not think that "it" was doing nothing.
I know, for example, that it has to refresh the screen, and check for
inputs, and do other chores, so it is doing something.

Just not what it was supposed to be doing, otherwise I could have used
the PC instead of being forced to reboot it.

It was just doing nothing that I had told it to do.
It was not running anything extra (beyond the operating system) that
could have locked it up.
I was not clicking a million icons a second, or trying to open 50
documents at once.
It was just setting there minding its own business.
Post by J. Francis
Ironically enough, most unexplained "lockups when the computer's just
sitting there" can be attributed to graphics/GDI problems. Yes, that
simple "lighting of pixels". It's one of the most bug prone facets of
modern PC's. Those lockups that can't be traced to display issues are most
frequently hardware and "heat" problems.
Well, the PC locked up running win 95, but that same PC did not lock up
running Win 3.11 and DOS 6.22, so that sounds like a coding error to
me.
The fact that they made an error in coding the display portion of there
software is interesting, but did not install any more faith in
Microsoft's ability to sell me a product that actually did what it was
paid to do.

And as to heat problems, we ran into them too.
But that is not what I am talking about here.
These were totally software related problems.
Even if it was that the software would not run on our commonly used
chips, it is still a software problem, considering that Microsoft
refused to sell us the operating system that he already had and forced
us to buy one that commonly locked up.
Post by J. Francis
Post by CanopyCo
errors were due to the software writer not doing his job correctly and
getting all of what I call bugs out of his software. They were not due
An impossible goal. The concept of completely bug free code is a pipe
dream. Wishful thinking. It's simply not humanly or physically possible
given any significant piece of programming. And if you would happen to
come close, the display drivers on one machine running your code could
walk all over it, and on another it might encounter an odd BIOS
incompatibility because it's so "rigid" it can't deal with some screwy
environment issue that translates drive geometry in one of the 10 billion
ways you didn't think of.
Apparently, you have already forgot what I call a bug.
Remember, bug is coding errors.
Coders cannot go back and fix there typos?
Cannot fix there math?
Cannot fix the improper use of code when doing a job?

We are not talking about vulnerabilities here.
Post by J. Francis
Post by CanopyCo
to viruses, or any other software running on the PC. They were inherent
in the Win 95 edition 1 software. I know this from tests that I ran
using various PC that did nothing but set there with nothing on them
that did not come on the Win 95 disk.
That's completely irrelevant. That certain versions of a software have
their own "quirks" is given. What you're failing to understand is that
those problem have causes, and those causes are usually called... bugs.
You must work for Microsoft, or are one of the type of computer people
that are giving computer people a bad name.
Microsoft changed something, and now it does not work.
And that is not there fault?

They are called coding errors when the new version has them and the old
one does not.
They changed something, and now it did not work.
That is a coding error, introduced with the change.
You could call them an introduced vulnerability, but that would make
them no more desirable then calling them coding errors.

And they would be able to fix them by simply coding that portion the
same way they did it the last time, instead of changing it so that it
now had problems.

If it is not broken, and is working just fine, then don't fix it, and
obviously don't break it.
Post by J. Francis
Post by CanopyCo
Post by J. Francis
Again your drastically over simplified view of reality has lead you to
a completely erroneous presumption.
Ok, look here, "lock up", to anyone but you, means that when I push a
button or move the mouse, nothing happens. No matter how long I wate, or
what buttens I push, I can not get any use out of my PC untill I reboot
it.
That's the effect, not the cause. That's what you see, not what made it
happen.
What made it happen is that I quit using an operating system that
worked, called Win 3.1 and DOS 6.22, and started using an operating
system that had coding errors in it called Win 95 edition 1.
Post by J. Francis
Post by CanopyCo
And win 95 edition 1 did lock up quite regulairly. I was selling PC at
that time, and sold quite a few coppies of win 3.11 and DOS 6.22 becouse
they came back complaining about just exactly that.
I remember the era well myself. Doing the exact same thing. Downgrading an
entire law firm in fact, after their "experiment" with early versions of
95 caused them so many problems.
What can I say... I tried to warn them off being on the bleeding edge but
Boss Suit was a self proclaimed technophile. The invoice reflected my
dissatisfaction with his denial that I knew best, as well the weekend it
took me to rebuild all their workstations behind his self imposed
"upgrade". Fortunately, God and I favored them by having designed their
network around NT servers, centralized data storage, and overly
cautious backup routines. ;-)
We are on the same page there.
When Win 95 came out, I could not imagine that a company could legally
get away with selling something that was clearly faulty and not get
sued for the damage it caused.

That is when Microsoft came out with there fancy contract that made
them not responsible for anything that they did.

My costumers had the same problem that I did at first.
They could not believe that such a big company would intentionally sell
a product that would create so much ill will toward it. :-/
Post by J. Francis
Post by CanopyCo
If you do not know what "locked up" means, then your abilities are
definitly is question.
I'll match my ability and experience against yours ANY day.
In programing or tech support?
You may be a programing God, but your communication abilities to the
common man is not God like. ;-)
Post by J. Francis
Post by CanopyCo
You ever do any customer support?
Geee lemme think.... I designed and built the county wide library network
in my home state, built and sold the hardware and maintained the network
at the local courthouse law library and Judge's chambers, built/supported
a considerable amount of hardware for three area hospitals, Built and
administered the network for a moderate sized international law firm,
built and administered the network for a large medical support group
comprised of about a dozen area physicians and their staff, built,
supported, and trained all the employees in the use of the new equipment
and software at a printing house that produced a bi-weekly "shiny sheet"
type newspaper (among other things), built and supported standalone
machines and small "networks" to probably thousands of people and
businesses over the course of the almost two decades I was in that
business, sold my services as nothing *but* a trainer and consultant to
many hundreds more, and even built some of the equipment and consulted on
my home town's first public ISP, then sold accounts and supported it from
the storefront I worked.
Support? *laugh* I could solve problems over the phone in my head by
visualizing the Windows menus and configuration screens while was
troubleshooting a CAD machine for a local machine shop and hammering
together a new machine for the hospital. Which at one time I could do in
less than 9 minutes from a pile of parts to an assembled box happily
accepting its operating system. :)
I spent 8 years coding 65c02 ASM language for embedded medical equipment
applications, where code quality was absolutely critical and examined by
government auditors on a regular basis. I coded a couple rather less than
significant utilities for BBS SysOps in C ages ago, and wrote a couple
"Door" games that became quite popular on the select BBS's I donated them
to. In fact my first experience with "grownup" coding issues inherited
from others was with the TriDoor library. I've designed and built a number
of significant commercial web sites from the ground up, including a custom
shopping cart written from scratch with a PHP front end and a back end in
Python (I love Python). I have (checking...) 17,921 lines of custom code
on this machine alone that I'm using or have used just as "problem
solving" crap for my own purposes, and I'm currently involved in a
collective coding project relating to, imagine this... computer security
and user privacy.
And that's just the fraction of my more or less professional experience I
recalled off the top of my head for your benefit. My resume is
considerably more impressive than that. On the civilian side I also ran a
BBS for a good number of years and dealt with all those questions. I
hosted/ran one computer user group and participated as a "guru" in
another. Presently I'm semi-retired building and selling Linux boxes
basically at cost to retirees and shut-ins in my area, and training them
on how to use their nicely customized, secure, and stable machines to see
those pictures of the grandkids.
IOW, I'm that "computer guy" with the brain everyone always wants to
pick, and it's been that way for a very, very long time...
Wow!
All that experience, and you still not only cannot communicate with me
well, but are constantly incapable of recognizing the experience that I
have in the field.

You must be getting rusty in the field of talking to those that are not
computer gods. ;-)
Post by J. Francis
Post by CanopyCo
If so, how, when you do not know what "locked up" means?
I know exactly what you're talking about. You're confused about why they
happen. I'm anything but.
Nonsense, I know exactly where the problem lies.
It lies in the programer changing something in the operating system,
form a method that worked to one that did not.
Post by J. Francis
Post by CanopyCo
Post by J. Francis
also when I write a peace of software that is designed to put out a
report doing math, and the report shows incorrect math.
I thought you claimed you *never* made a mistake...?
Oooops... :)
I clamed that I never let a peace of software get to the costumer phase
with a mistake in it.
That you're aware of or will admit to anyway. ;)
I don't give customers software that is not fully tested and working
properly.
And yes, I do check back to see if there is even anything that they
would just like changed, even though it is working just fine as it is.
Like maybe screen 3 and screen 5 combined instead of separate.
Or the order of data entry questions, or anything at all that they
noticed that they would like changed.

I am not Microsoft. :-)
Post by J. Francis
Post by CanopyCo
I never clamed that everything I wrote compiled correctly the first
Compiling without errors and running perfectly under every condition in
every scenario are two completely different animals.
And our difference in word use is why you were not aware that I was
talking about zebras, and you were talking about black and white
horses.
Post by J. Francis
To be brutally
honest, the sort of programming you're talking about is so limited in
scope that the chances of you making less than obvious mistakes were nil.
:-p
Go suck a hard boiled pickled egg.
:-)

I consider the PC locking up while just setting there to be a pretty
obvious mistake.
And yet big shot programers like Microsoft could not catch that before
it hit the market.

Eh, I do what I can, and I take pride in my work.
Too bad that there are so many computer people out there now days like
Microsoft that don't.

And no, I am not saying that you are one.
After all, I have never ran any of your software, so I have no idea
what quality of work you put out to market.
Post by J. Francis
Still, I'm surprised that you weren't aware of, and use to working around
the bugs that I remember popping up from time to time in various COBOL
compilers.
Never ran into any.
But then, as you said, I was a data processor and report generator.
Furnishing the local businesses with the type of software that the
majority of business use every day.

Like video stores, so that they can keep track of there inventory and
customers.
Or nursing homes and disabled work shops, so that they can keep track
of there clients and print out the government reports without a bunch
of hassle.
Or ware houses so that they can keep track of inventory, shipping, and
receiving with ease.

It isn't as flashy as writing operating systems, but it was what was
needed by the common man who was being screwed over by the flashy
writers.
Post by J. Francis
Post by CanopyCo
time. I also said that I kept at a peace of software until I got it
right, instead of selling it and claiming that it was impossible to fix
it.
You're being obtuse and childish again. I never said it was impossible to
fix an error, I said errors would occur. And that outside the realm of
trivial coding tasks it's humanly impossible to account for every
eventuality or scenario.
Not being obtuse.
Just demonstrating that previously noticed difference in word usage.
Remember?
Bug (when used by my) means coding error, not vulnerability.
And coding errors can be fixed, but not all vulnerabilities can be
addressed or even thought of before finding them in the users world.
Post by J. Francis
Post by CanopyCo
Post by J. Francis
Fact is, I restrained myself considerably because I believe that YOU
believe you're trying to solve some debate.
Basically, yes, I am trying to understand how things have changed from
the 80's when I wrote software to now, in such a manner that it is now
impossible to make things as dependable as they once were.
Nothing has changed. And after the wash out your perceptions were as
incorrect then as they are now. The only thing that's really changed is
the sheer size of the problem.
Post by CanopyCo
Your inability to teach is in no way an indication of my inability to
learn.
Abilities have zero to do with it, you're aggressively fighting the
lesson... *shrug*
That can be just as much a problem with the teacher as it can be the
student.
Post by J. Francis
Post by CanopyCo
You simply have no intention of teaching. Just insulting.
I'm just stating facts. You apparently have absolutely no interest in even
the things that common sense should tell you without any help for anyone
at all. The "pixels on a screen" idiocy is a prime example. I've explained
to you now a couple times that it's a tad more involved than that, but you
keep singing the same old song like you never read a word of it.
Your missing my point.
If I can do a job in a simple way, then why make it more complicated?
But apparently, there is a need for the increased complication.
I don't know if there is or not.
And I can't count on you to say if there is or not either, sense you
obviously have a love for things being complicated.
Where I have a love for keeping things as simple as possible and still
get the job done.

It's a difference in how one looks at things.

I would use DOS and a simple BASIC or COBOL program for a local video
rental store.
You would use Win XP and Visual BASIC, and have to deal with all the
limitations and problems that came with the more complicated stuff.

But this is all off topic, really, sense what I was originally trying
to talk about is a simple chip reader. :-/

You're
Post by J. Francis
actively avoiding even trying to learn anything from where I sit.
Combatively discarding what you dislike, and parroting your thread bare
misconceptions in spite of the compelling evidence that's right in front
of your face.
And you are ignoring the concept that there is no reason to make a
simple job complicated.
The fact that someone else has made a simple job complicated is no
indication that it could not have been done simply.

<Sniped a bunch of babble where what I was saying is not even remotely
what you were hearing>
Post by J. Francis
Absolutely not.
First of all, we're not talking about a "JPG editor", we're talking about
myriads of programs that handle even more types of graphics files.
Not talking about a JPG editor?
Why the hell not?
I am talking about a JPG editor.
Why aren't you?
Just what part of JPG editor did you think mente myriad's of other
programs?
Maybe if you would just stay on the subject we could communicate
better.
Your throwing a fit and getting frustrated because you keep changing
the subject and I don't?
Post by J. Francis
Second, the exact bug we were talking about earlier had nothing to do
with any specific "JPG editor", it was a flaw in what essentially boils
down to the operating system, that was "inherited" by various other
programs like web browsers, spread sheets, word processors, and yes...
even "JPG editors".
There we go.
Communication at last.
The problem was not with the editor, but the operating system that it
ran on.
I can understand that.
After all, Microsoft is full of things like that.
Vulnerabilities that get taken advantage of.
And no JPG editor writer can change that.
Because the problem is not in the editor, it is in the operating
system.
Why didn't you just say that in the first place?
See how simple that it?
No need to drag all that other crap into the subject.
Obviously no need to discuses the problems of myriad's of other
programs.
Post by J. Francis
Third, there is by no wild stretch of the imagination what you could call
even a small number of bugs that have been discovered in programs that, in
essence, only manipulate pretty pictures. They can generally be classified
into a small number of general types, but the individual bugs probably
number in the many thousands if you travel back through history. Some
are severe, some are minor, they all have their roots in some fairly basic
and undeniable principles, and they're all as different as the individual
coder who wrote them and the unpredictable machines that run said code.
I take it that you are talking about vulnerabilities again, not coding
errors?

In order to properly determine where the problem lies, one must make a
distinction between the two.
Post by J. Francis
Post by CanopyCo
Post by J. Francis
Oh, and by the way, several methods for including unwanted or
clandestine information within bar codes have already been developed
and implemented. And bar codes have been exploited for nefarious
purposes. So it's not completely beyond the stretches of imagination
that malware could be encoded in bar sequences. If a suitable bug in
the firmware running the bar code readers is discovered, anything is
possible.
[...]
Post by CanopyCo
What are they doing, using a serial or parallel port to access the input
form the bar code readers now days instead of the reader having its own
memory chip?
What "memory chip"? You're reading information, and you have to do
something with it. That by *definition* means processor and at least
firmware. Whether it resides in the reader or externally is irrelevant. If
you're scrubbing data in the reader there's a processor there. If not,
it's passing the "whatever" it's reading.
Typically the wand itself is a "dumb" device that interfaces to a
terminal. The "cash register". That cash register runs <gasp> Point of
Sale software. That device in turn is almost always wired to some sort of
inventory control infrastructure back behind the swinging doors beside the
customer restrooms... or maybe even in a different state.
You didn't answer my question.
Is the information going directly to the computer and its operating
system?
Or did it pas threw its own storage system that would automatically
truncate it down to the proper size?
If it did not, it should, for that will solve this entire problem.
Once it is formatted to the proper size, and sent as a number, and
handled as a number, then there is no way for malware to do anything.
Just as when you type a number into a calculator, then connect the LED
output to an input for a spread sheet.
No matter what you hit on that calculators keyboard, it will just be
numbers.
And the spread sheet can except all those numbers, and will just do
math with them.
Post by J. Francis
Post by CanopyCo
Post by J. Francis
Memory in a "digital" machine is allocated and accessed in segments.
It's a hardware limitation, impossible to circumvent completely. For
that matter, even completely analog processes have bounds and limits
that can be breached. It's really a limitation of the physical world,
in a sorta Zen-like way.
Exactly that limitation is what I am looking at. The input from the bar
code reader comes from the reader. It likely comes in as a parallel
input, sense the bar code is read as a single line.
Those readers are almost always serial devices in my experience, but
my experience is trivial and it's completely irrelevant in any case. The
shape of the data isn't important, the variability is.
Serial is even better.
The memory chip in TTL is loaded from one end with a 1 or 0, and that 1
or 0 is clocked to the next location as the new 1 or 0 is loaded.
Once the clock hits 8 ticks, it quits.
After all, the chip only has 8 locations for a 1 or 0 to be stored.
After that, it is sent to the PC for the software to use as a number.
No buffer over run possible, sense it will never receive anything but a
group of 8 1's and 0's.

If it is not done that way, then someone with a little knowledge of
hardware can make a simple "filter" that would totally do away with any
chance of malware entering the system threw the scanners.
Post by J. Francis
Post by CanopyCo
From a RFID chip it would likely come in as a serial input.
No, actually it's a pulse modulated signal with data being read off the
trailing edge of the pulses. A series of signals are generated and the tag
"echos" in a certain way depending on what data it holds.
It isn't the old handshake type of thing?
Where the reader sends a "send me the data" signal, then the chip sends
a "here it comes" signal, followed by a series of 1's and 0's?
Post by J. Francis
Post by CanopyCo
Now, if the reader had its own memory chip that captured and stored that
information until the software took the information and then reset the
chip, it would be immune to any form of bad ware input.
Irrelevant. At some point software picks up the data and the fun begins.
But that software is, or should be if properly written, capable of
handling any combination of 1's and 0's of the desired size and treat
them as nothing but a number that is cross-referenced to a database for
future activities.

Sending that software the number 10011001 should do nothing to it that
was not listed in the database, as it did not over run the buffer, due
the hardware memory chip not sending to fast, or to large.
Post by J. Francis
Post by CanopyCo
Due to the
memory chip only holding the expected amount of digits. And they would
still only be 1's and 0's.
It's *ALL* only 1's and 0's. The data, the software diddling it, the drive
controller firmware on the storage device that archives your address for
future junk mailings... *ALL* of it.
Exactly.
And how one handles those 1's and 0's determines what happens.
If I run an ASCII program the same 1's and 0's becomes a "R".
If a run a math program, that series of 1's and 0's becomes a number.
The only way for malware to work is to get out of the program that
handled the 1's and 0's in the proper way, and into an area where it is
handled improperly.
That would be prevented if there was a hardware "filter" that prevented
the data from being to large or coming in to fast.
Then it would just be handled as the number that it was expected to be,
and nothing bad would happen that was not listed in the database that
the number cross referenced to in order to know what to do.

For example, if my database receives number 11000110, then decrease
inventory of item number Mo-123-xph by 1, display price of $5.95, and
add price of $5.95 to total at register. Go to check inventory for
reorder. Reorder; if total of item number Mo-123-xph < or = 25, then
send out order for restocking.

Nothing bad happened.
And there is a listing for every one of those possible combinations.
If not, then there is a line saying; If number input not found in
database, display "part not found" and go to next item.

Now, nothing bad can happen from anything that came from the RFID chip.
Because the software was properly written to handle all possible
combinations of 1's and 0's expected from the chip.
And nothing unexpected from the chip can get past the hardware
"filter".

If it is not done that way, it should be.
Post by J. Francis
Post by CanopyCo
And as to overload from to much coming from the RFID chip, that can be
addressed this way.
The hand scanner sends out a signal, we will call it "give me the data".
At that point it starts receiving the data, likely in serial sense it is
a radio signal, and starts loading it into its memory chip. Now, once
that chip is full, it stops taking input. That is done with hardware. It
has a counter, and counts the number of inputs. When it get the right
number of inputs, it quits taking input. Doesn't matter if more is
coming, because it's memory chip is full and it has stopped taking
input.
That's essentially how it works *now* with a few exceptions, and it's been
proved vulnerable. The problem isn't taking a specific size of data off
the tag, it's processing that information. Your "preprocessing" theory is
fundamentally flawed because the data isn't consistent in length or
segmentation. You're describing a scenario that simply does not exist in
the real world. Sorry.
There is the problem
It is not consistent in length or segmentation.
It should be, so that this problem would be gone.
If it were always the same size, then the software would know what to
expect, and it could deal with it properly.

And there is no reason that it cannot be.
Just that it isn't.
Now that we have determined where the problem is located, maybe you
could make yourself some bucks by fixing the problem.
All you have to do is make your system use a set sized data, so that
the software is never exposed to a size larger then it can handle, nor
is it exposed to a series of 1's and 0's that it did not have a use
for.
Post by J. Francis
Post by CanopyCo
Now you have a simple number.
It is the right size.
And it is handled as nothing more then a serial number. If it did not
Not possible. That would make RFID tags utterly useless. I believe at
current most RFID tags carry 128K of memory space. In that space you will
find APC, dates, manufacturer and retail location information, and
probably a lot of other garbage. It's all necessary for things like
letting you trundle through the exit with your new DVD copy of your
favorite movie without setting off the alarm, while still triggering that
same alarm when the guy right behind you tries to leave with the copy
of the exact same movie he shoved down his pants.
And *that's* just your local shopping mall RFID tag.
Don't forget they have medical and law enforcement applications too,
including things like having codes for your allergies and heart attack
history available for immediate retrieval, and contact information for a
lost pet's owner.
So, it is basically how the information is being used that is the
problem.
The over all system.
If they would use it as a number, instead of a generic memory device,
this problem would not exist.
And it does not have to be done that way.
Just that it is.
They could store a serial number on that chip, and use what ever came
off of it as a number.
Then that would solve all these problems.
So, it is not that they can't do it in a safe manner, just that they
aren't.

Maybe you could make yourself some bucks writing a program that used it
in the manner that I suggested, with the hardware filter that I
suggested, and market it as virus proof.
Post by J. Francis
Again you've run into that over simplification wall head on. It's
obviously impossible to treat data stored on an RFID tag as "a simple
number".
Why?
If all I stored on it was a number, then why could I not treat it as a
number?
And doing it my way, the simple way, would totally do away with the
virus problems form now on with that product.
Post by J. Francis
Fact is, it's cost prohibitive to design them in such a way that
they can only store a certain amount of numbers of a certain size, because
customer "A" will have different data requirements than customer "B". That
means leaving all 128K open for "flat" R/W and dealing with data field
sizes and quantities in software.
Hold it, they are allready only capible of holding a number of 128K in
size.
That is a set and knowen size of number.
You said it was imposible?
And by doing it my way, with it only being a number and being handled
as a number, you can fufill all those diferent needs.
Simply put diferent stuff in the database that you cross referenced
with that number.

Keeping track of your dog?
Number 1100110 crossrefferences to the Black Lab belonging to Bob
Barker on Pound Street.

Ok, I think I see the proublem now.
Number 1100110 in wallmart will crossreference in there database to be
a pack of penuts.

Hummm, still, they are allready all just getting 1's and 0's.
So why is this not happening anyway?
Are they formating the information as somthing comon like a TXT
document, so that all readers that open it is capible of reading it and
they just sort it out at that point based on the contents?

Like in the abouve, when they opened that document, the penuts chip
would say "Big Boy Penuts, 10 oz can", where the dog would say "Bob
Barkers Black Lab form Pound St"?

Is that what is going on?

They could allocate number groups to users, like they do frequencies
now.
That would solve that problem.

After all, a fake chip with fake prices in it is going to be a problem
no matter what.
But at least this method would stop someone form draining Walmart's
bank account.
J. Francis
2006-03-23 23:30:02 UTC
Permalink
Post by CanopyCo
It appears your communication skills are as broken as my using 80's
definitions when talking to a 06 person. ;-)
No, it's your motives and/or ability to comprehend that are faulty. For
instance, I *plainly* explained how a specific bug we were discussing was
an operating system issue, and in reply it was is if you never even saw
the words when you claimed to be enlightened, yet called it a "JPG
reader" problem once again.

It's absolutely incomprehensible that anyone could post that sort of tripe
and not simply be playing childish little games. In fact, given a choice
between game playing and that level of inability to understand simple
logic and small words, I'd have to go with game playing. It's a lot less
embarrassing.
Post by CanopyCo
And they would be able to fix them by simply [...]
Your propensity for trying to simplify something so much it becomes a
clownish parody of itself and then blaming others for that inanity has
become as tedious as it is inherently flawed. The facts have been handed
to you, do whatever you want with them.

This discussion is off topic for misc.survivalism, so by all means feel
free to take your silliness to some technical centric group and find out
how it fares in that environment.

Best of luck...

<EOT>
J. Francis
2006-03-23 12:00:02 UTC
Permalink
CanopyCo wrote:

<kersnip>

Here's a fascinating article about a recently discovered Microsoft
Internet Explorer bug. Fascinating to me anyway. *shrug*

http://www.securityfocus.com/archive/1/427904/30/60/threaded

It's a real good testimonial to just how convoluted this sort of thing can
be. There's a considerable amount of technobabble, but the points that
should stick out are things like pages accessed *before* a page with the
exploit, and which browser extensions have been recently accessed, can
affect the outcome; and the fact that it might not even manifest itself
immediately, but leave things in an unstable state that results in
problems later on.

In fact this one bug demonstrates much of what I'm telling you including
inheriting problems from elsewhere, apparently unrelated factors
contributing to a problem, the vast amount of uncontrollable influence
that might cause problems, and even how behind the scenes operations might
give the appearance of something happening when the computer is "just
sitting there".

Like I was saying... there's more to it than flipping a switch. ;)
CanopyCo
2006-03-23 18:43:58 UTC
Permalink
Post by J. Francis
<kersnip>
Here's a fascinating article about a recently discovered Microsoft
Internet Explorer bug. Fascinating to me anyway. *shrug*
http://www.securityfocus.com/archive/1/427904/30/60/threaded
It's a real good testimonial to just how convoluted this sort of thing can
be. There's a considerable amount of technobabble, but the points that
should stick out are things like pages accessed *before* a page with the
exploit, and which browser extensions have been recently accessed, can
affect the outcome; and the fact that it might not even manifest itself
immediately, but leave things in an unstable state that results in
problems later on.
In fact this one bug demonstrates much of what I'm telling you including
inheriting problems from elsewhere, apparently unrelated factors
contributing to a problem, the vast amount of uncontrollable influence
that might cause problems, and even how behind the scenes operations might
give the appearance of something happening when the computer is "just
sitting there".
Like I was saying... there's more to it than flipping a switch. ;)
Wow!
It just goes to show, the more complicated the system, the smaller
wrench required to mess it up, if it is thrown into the works. :-/

Some times I really miss the simpler days. :-/
Offbreed
2006-03-23 02:43:27 UTC
Permalink
Post by CanopyCo
You cannot get a virus from a bar code reader.
Might be able to with a long enough bar code. It would not make any
sense to do it, but I would not bet against it being possible.
J. Francis
2006-03-23 07:15:02 UTC
Permalink
Post by CanopyCo
You cannot get a virus from a bar code reader.
Might be able to with a long enough bar code. It would not make any sense
to do it, but I would not bet against it being possible.
Ever since bar codes were mentioned I've been desperately (well sorta)
searching for an article I read years ago about some college students
cracking a bar code scheme and devising a sticker that essentially dropped
the price on a given product line by any desired amount. IOW, once a
sticker on a VCR was scanned and the price adjusted to $9.95, all further
scans would come up with that price until someone caught on. Something to
do with an inventory control program resetting something when the number
of in stock items reached zero or such, and a clever way of making the VCR
appear to be the last one.

Ok, not a virus, and I'll be DAMNED if I can cite it right now, but a real
good example of what's possible none the less. ;)
Winston Smith
2006-03-24 22:44:29 UTC
Permalink
Post by CanopyCo
A question just came to mind.
If it is impossible to fix the problem with JPG readers that has been a
problem ever sense Win 3, then why is it that Macintosh and LINUX
computers don't have that problem with there JPG readers?
Because they don't execute Windows code embedded in the infected file.

--
W§ mostly in m.s - http://members.1stconnect.com/anozira
Winston Smith
2006-03-24 22:52:08 UTC
Permalink
Post by CanopyCo
Yes, I remember hearing about that.
And that is one more of my gripes toward software writers of today.
A JPG is nothing more then a still photo, rendered on the screen by
lighting up a series of lights (called pixels).
That is sort of true for a .bmp - bit mapped picture. That's why they
are so huge.

A .gif and .jpg are encrypted data files that are operated on by the
viewer by running an algorithm and doing what the data file tells it
to. Somewhere I have an article telling a programmer what steps they
must take to prepare a jpg for the screen. It's a long complicated
business. They are much smaller because it's easier to mail you a
recipe for a cake than it is to send the cake.
Post by CanopyCo
So, all a JPG reader needs to do is go threw a list and light the bulbs
that it said to light.
Nothing more.
Same reply as above.
Post by CanopyCo
Kind of like the peek and poke type of programing from way back in the
old days.
Early viruses did just that - poke things where they shouldn't be.

--
W§ mostly in m.s - http://members.1stconnect.com/anozira

Winston Smith
2006-03-24 22:42:20 UTC
Permalink
Post by CanopyCo
Post by Winston Smith
From the article
"Researchers at the Amsterdam's Free University
created
a radio
frequency identity (RFID) chip infected with a virus to prove that
RFID systems are vulnerable despite the extremely low memory capacity
on the cheap chips."
The point is that bad guys don't follow the official rules. They can
build a chip with anything they wish in it. The objective is
malicious - to crash large computer systems.
That does not change what the reader is expected to do with the
information that it receives.
It should not be running anything it receives.
It should be reading the 1's and 0's as data and just disregarding
anything that it did not recognize.
Just like opening an exe file with notepad.
If it isn't, then it would be a simple change to make it that way,
though I have no idea why it would be anything other then that already.
I'm not expert enough to explain 'why', but as someone else pointed
out viruses can do their thing by you getting - but not opening - an
e-mail or looking at an image.

As to the question of RFID, remember the bits read by the scanner go
to a database computer. They know about macros. Every time I open a
spreadsheet with macros in it, I get warned it could be risky. Most
MS office products can be attacked by their 'harmless data files'.
Post by CanopyCo
I still think that this article is more propaganda.
Especially with the blurb about chips allowing government to track
airline tickets.
They already do that without the chip.
Caught in one lie.
Makes the rest questionable.
Make a distinction between the science guys that actually achieved the
deed and the reporter that wrote the article. The reporter is the guy
that decided to tie his airline thoughts into what the tech guys said.
Post by CanopyCo
Try this.
A virus is a executed program.
It has to be ran, either directly or by some other running program.
Now, pick out some exe file on your hard drive.
Just in case, copy it to somewhere and rename it test.txt.
Now, open that file using notepad.
Now open it with Excel or Access or some such and see if you are safe.
I doubt Walmart is running their network with notepad files.

--
W§ mostly in m.s - http://members.1stconnect.com/anozira
Strabo
2006-03-21 03:51:36 UTC
Permalink
In Re: RFID chip barcodes can carry a virus on Sun, 19 Mar 2006
Post by Winston Smith
Post by j***@gmail.com
Post by Offbreed
This is true, for now.
yah, "for now" leaves alot open for the future.
Except, they're that way by design. If they were meant to be written
to on the fly, they would have just incorporated the writer with the
transceiver, as I'm sure they've done in other cases with the active
RFIDs. They have no reason to though, because for the purpose of
tracking and 'sending' information (which is the intended use of
passive RFIDs), they have no need to write to them. Thus the article is
pointing fingers at a dead duck.
From the article
"Researchers at the Amsterdam's Free University
created
a radio
frequency identity (RFID) chip infected with a virus to prove that
RFID systems are vulnerable despite the extremely low memory capacity
on the cheap chips."
The point is that bad guys don't follow the official rules. They can
build a chip with anything they wish in it. The objective is
malicious - to crash large computer systems.
Correction - to manipulate computer systems. Crashing is just one
option.

There are corps that are interested in this technology aside
from the primitive goal of point-of-sale and inventory control.

A partnership was formed several years ago to trade information
about individuals with detectable RFIDs. For example the RFIDs in
clothing will be detected each time an individual enters a store,
bar, movie, etc., and what he may purchase. Some types of RFIDs
(non-passive) may also be updated on the spot. This info along
with time/date/place stamps is made available to partners who
will update the individual's record.

Government is also in on this surveillance bonanza. Court
decisions have already gone in favor of requiring corps to
turn over consumer records.

In addition to the consumer style RFID there is also the
implantable type. This RFID can be a bona fide transceiver
energized by the individual's body and capable of operation
independent of reader/transponders such as medical versions
that can act upon the host's body.

The virus can be placed on a suitable RFID by using the
same reader/transmitters that stores and government will use to
collect info. A virus might include a capsule designed to be
uploaded to a host computer where it can seek an internet
connection or a WI-FI where it can call home with info regarding
it's environment and/or receive instructions.

Once out of the RFID and into a viable system, a virus
can do whatever any other virus can do.

Just think, as you leave the shoe store with new shoes and
a builtin 1Mb transceiver (battery or thermal generator) with
your identity and consumer info (downloaded at the register) and
programmed against your interests. A virus introduced into such a
system could find its way most anywhere. It could "jump" to your
cellphone, notebook or any WI-FI network, or perhaps the computer
network where you vote.

The solution is a high powered detector/sniffer/jammer/killer
that will block or read the output or overload the inputs of
transceivers.

Electronic devices have become injurious to the human condition.
Soon your only choice will be to stamp on them as you would
cockroaches, if you can find them.


----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Offbreed
2006-03-17 02:02:24 UTC
Permalink
Post by CanopyCo
Now, if I am only expecting a txt message from the chip, then why would
I run it as a program?
The computer is set up to run automatically. You remember the .wmv
(wmf?) exploit scare just a few weeks ago? The malware made use of a
poorly designed error handling process.

alt.comp.anti-virus has a bit more discussion on this.
Paul L.
2006-03-20 18:15:10 UTC
Permalink
Another story on this...

http://reviews.cnet.com/4520-3513_7-6466679-1.html?tag=nl.e757
Continue reading on narkive:
Loading...