MonMotha
i do not as a rule correct
but u are wrong
the dallas key is cryocrypted before loading to the chip
without there os u cannot dump the ic2 chip chain
which u must ask for and be a member of there forms in good standing to recieve
same with the xlink crap
so having a home built dumper may work ?
but with out the hash,the chk-sum will never be right
so in short loading a blank is a 50/50 1 off
with the current dump u are working with
hence the reason for the batt back up-on chip
to save the nv-ram contents
so please i have dealt with this style system for well over 20 odd years
from video games straight through to pos systems >point of sale<
up to and into the crypto for batt loader cards
u must watch the last part of the chk-sum
the easy way was to convert
bin to hex or bin to img
then back again to hex
u then get the proper hexcsum
ed
I'm sorry, but what does Dallas (aka Maxim) semiconductor have to do with this? It's an ST part. Are you saying it's a clone of a Dallas part? Dallas did make a ton of this sort of thing, so that's possible, I guess. Are you trying to say that this part has a ton of functionality that's just totally undocumented in the public datasheet? That's possible, I guess...one ARM9 CPU I used a few years ago apparently had a GPS receiver built into it that wasn't even mentioned in the datasheet, but that was apparently because it didn't really work.
Dallas does also have a large lineup of crypto memories. IIRC, they all have a 1-wire interface, but maybe some are I2C. They're available as little chips or in the larger "iButton" format. These are chips that do MD5 using a pre-programmed secret. They have a unique ID (factory set) number on them, but IIRC it's up to the buyer to set the MD5 secret on all of them. They are quite commonly used for copy protection systems and for things like printer consumable tracking/restriction. Some of them, especially older ones in iButton formfactor, are battery backed RAM internally, not EEPROM/Flash. These parts are well documented, publicly. You don't need their "OS" or anything, though you do need a 1-wire master (and they have an FPGA HDL implementation) and a driver of some sort to talk to it. They provide all the info you need to create those yourself, though if somebody has already loaded an MD5 key onto the part, you're sunk (there's a good chance that Dallas doesn't even have it).
Xilinx has a kinda-sorta related mechanism for bitstream protection where you can load a crypto key into some battery-backed SRAM on the FPGA, and it will use that key to decrypt the bitstream it loads off an external ROM (people commonly use the Xilinx "Platform Flash" for this, but you can use other industry-standard flash parts) on-the-fly during powerup/program.
Atmel also has a series of "cryptomemories" though I'm not aware of any of them that are battery backed. Atmel doesn't release full datasheets on these parts, though the datasheets they do release are clear that they're incomplete and do not document all aspects of the part. The teardowns I've seen show them to be of somewhat questionable security. They tend to focus more on data confidentiality than integrity, which is a harder problem to solve. These DO have a factory-installed key of some sort, though the user can also assign a key. I'm not sure what operations are related to which keys.
Then of course there's all sorts of little embedded CPUs intended for use in smart cards and other smart "tokens". These are usually very difficult to work with as they include several countermeasures to prevent data extraction and copying - that's the whole point of them.
Now, assuming the part under discussion here (ST M48T58/Y) really is just what's documented in the public datasheet from ST...
There's surely a checksum or similar in use in the data that's on the part, but it would be application specific and application implemented. It may be cryptographic in nature - e.g. using a known secret (HMAC style), but Dallas would have nothing to do with distribution of such a secret, and the entirety of the data on the chip is exposed, bare.
The ST M48T58/Y is not one of these Dallas crypto parts, nor is it an FPGA, nor does it have an embedded CPU or any documented data extraction countermeasures... It's a bog-standard parallel bus interface battery-backed NV SRAM+RTC. Same thing my old Sparcstation had, and similar to what all my old PCs had before they got integrated into the southbridge/SuperIO. I'm sure you've encountered a system like you speak of - they definitely exist and are downright common in copy protection systems - but this doesn't appear to be one of them. It's just a data dump with a clock.
Now, it goes without saying that you need a dump of one from BEFORE the battery died, and if the data is keyed (by the software) to a serial number or similar on the system, then it won't work on another system, but none of that has to do with Dallas (!?).