London Banter

London Banter (https://www.londonbanter.co.uk/forum.php)
-   London Transport (https://www.londonbanter.co.uk/london-transport/)
-   -   Oyster Card System Failure (https://www.londonbanter.co.uk/london-transport/6993-oyster-card-system-failure.html)

Roland Perry July 27th 08 11:45 AM

Oyster Card System Failure
 
In message
, at
03:19:55 on Sun, 27 Jul 2008, MIG
remarked:
My experience is that the management want to cover their backs WHEN
something fails, by saying "but we paid the most expensive
consultants".


They all charge about the same.

They could have spent an awful lot less on working with their own
staff to prevent it failing in the first place. I've seen that a few
times.


If they were in the habit of working with their staff, they might not
need the "rescue package".

And if it looks like the staff are failing (even if it's not the staff's
fault) they are likely to be the last place management looks to for new
skills to solve the problem.

But many of the staff's ideas, filtered and verified by the consultant,
can be exactly what the organisation needs.

--
Roland Perry

[email protected][_2_] July 28th 08 10:52 AM

Oyster Card System Failure
 
On Jul 26, 5:37 pm, wrote:
On 25 Jul, 21:43, Chris wrote:

Of course they can - incorrect data downloaded to cards can easily
makethem inoperable.


I've not yet come across r/w memory that can't be reset if theres
dodgy data on it so unless they're upgrading any software there may be
on it I can't see how it could happen. And if thats the case you have
to ask yourself why.

Most microcontrollers have had settings which once written prevent you
ever reading out or changing the microcode again.

Some of those were non resettable, even if, before the fuses were
blown, the microcontroller was reprogrammable.

(The modern flash PICs which I've been playing with recently all seem
to have the ability to do a complete reset even after the code
protection bits have been set - IIRC on some of them this reset can
wipe some of the factory calibration data so you have to make sure
you've recorded these values for the individual devices somewhere
before you start down this path - I think mostly this calibration data
is related to the internal oscillator so it's not needed if you're
using external timing)

I can easily believe that the mifare card could have a setting to flag
some of the memory as read only - IIRC sector 0 (which contains the
ID[1]) is read only - It's perfectly possible that there is an address
somewhere that says what memory is read only and what is read write
and that address can only be incremented, never decremented.

Initially the card is created with this address as 0. Sector 0 is
written and then the address incremented to 1. A card can be totally
disabled by incrementing this address to its maximum value.

Tim.

[1] Someone posted a link to a presentation about hacking the mifare
chip - according to that, even though sector 0 is non-reprogrammable,
you can change the key used to encrypt the traffic in such a way that
the card looks like it has a different ID. Only if the reader
explicitly requests sector 0 and verifies the ID will it be able to
detect this spoofing.


[email protected][_2_] July 28th 08 11:14 AM

Oyster Card System Failure
 
On Jul 28, 11:52 am, "
wrote:
On Jul 26, 5:37 pm, wrote: On 25 Jul, 21:43, Chris wrote:

Of course they can - incorrect data downloaded to cards can easily
makethem inoperable.


I've not yet come across r/w memory that can't be reset if theres
dodgy data on it so unless they're upgrading any software there may be
on it I can't see how it could happen. And if thats the case you have
to ask yourself why.


To followup:
Just found this 2K (256x8) eeprom

http://www.atmel.com/atmel/acrobat/doc0958.pdf

Has a permanent software write protection for the first half of the
memory.

"Write Protection
The software write protection, once enabled, permanently write
protects only the first-half of the array ...

The software write protection cannot be reversed even if the device is
powered down."

I've only skimmed that data sheet but it looks like if you send a
write command with a device address of 0110 instead of 1010 then
you'll set this bit.

You really don't want to send a software update to your readers that
drops a byte from the command being sent to the chip - most cards will
just fail to work, but a few will get that magic 0110 bit pattern at
the wrong point and will then be permanently broken.

Tim.

tim..... July 28th 08 05:58 PM

Oyster Card System Failure
 

wrote in message
...
On Jul 26, 5:37 pm, wrote:
On 25 Jul, 21:43, Chris wrote:

Of course they can - incorrect data downloaded to cards can easily
makethem inoperable.


I've not yet come across r/w memory that can't be reset if theres
dodgy data on it so unless they're upgrading any software there may be
on it I can't see how it could happen. And if thats the case you have
to ask yourself why.

Most microcontrollers have had settings which once written prevent you
ever reading out or changing the microcode again.


Yep, but this area isn't going to be written to by the application code. It
will (or won't) be blown deliberately during manufacture.

tim






All times are GMT. The time now is 03:00 PM.

Powered by vBulletin®
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2006 LondonBanter.co.uk