![]() |
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 |
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. |
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. |
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 09:46 AM. |
Powered by vBulletin®
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Copyright ©2004-2006 LondonBanter.co.uk