Potential DS1996 support?

iButton 1-Wire
#1

Adding DS1996 support to Flipper seems to be a good idea and should not take much effort. Emulation is also suggested.

Quick overview of DS1996 (header 0x0C) and it’s uses:
DS1996 is an iButton with 64kbits (8KBytes) of EEPROM storage (256 pages, each 32 bytes). One of the primary uses for DS1996 (in Russia) is for data transfer between systems. In the case of a system being replaced, moving data to a DS1996 is available in the case of the memory chip on the PCB not being readable (example: ELTIS DP-3/4XX, EEPROM fuse bits are locked from factory). Having the ability to read (or even have) a DS1996 chip is unlikely due to the rarity and high prices compared to other iButton devices (on average $15-$25 compared to $0.5 (DS1990A)).

Adding the format:
This message contains a datasheet for the DS1996 chip: DS1996.pdf (466.4 KB). The main point is the command 0xF0 (Read memory) which takes 2 arguments: offset and address to read from.

An example memory read will look like:
TX R //reset pulse
RX P //device responds
TX CC //0xCC command means “Skip ROM (serial number)”
TX F0 //0xF0 as stated is Read Memory
TX 00 //0x00 - Page offset is 0/F (one offset is 2 bytes long)
TX 00 //0x00 - Page number is 0/FF
RX [MEM, 8KB]

The read memory can be then either be sent to a PC in the form of a .bin or saved on the SD for later use.

Emulation
Emulation of DS1996, while possible, is difficult. DS1996 has a “scratchpad”, which can be referred to as “RAM” of its kind. Data that will be written to the EEPROM must be first written to the scratchpad, and only then from the scratchpad to the memory. Scratchpad interaction has 3 commands: 0F (write scratchpad); AA (read scratchpad); 55 (copy scratchpad to memory).

An example write to the 167/256th page, bytes 3 and 4 should look like (addr 14C1/1FEF):
TX R
RX P
TX CC
TX 0F
TX C1 //Offset 1/F. I did not understand this part in the datasheet, someone please correct me
TX 14 //Page 166/255 (0-255).
TX 3A44 //Send data, 2 bytes

TX R
RX P
TX CC
TX AA //Obtain the necessary end+flag data to run 0x55 command
RX C1
RX 14
RX 02 //This should be right. This is the end and flags information that the DS1996 chip sends which we have to use later.
RX 3A44 //The AA command can also be used for verification.

TX R
RX P
TX 55 //Copy scratchpad to memory
TX C1 //Transmit offset
TX 14 //Transmit page offset
TX 02 //Transmit end+flags

Memory can be read for verification with the F0 command: F0 C1 14.

Waiting to hear your opinion on this idea.

1 Like
#2

Hope that someone do make an app to implement this as iButton support aparently is “abandoned” by the dev team that didn’t even implenment writing to cyfral/metakon … If someone can make an app using the posted intructions to manage DS1996 that would be fantastic !

2 Likes
#3

Well, implementing support for writing TM2002 and DC2000A’s is impossible. Those are hardcoded from factory.

Sure, re-encoding exists (its based on how keys are stored) but it’s not officially supported so you’re stuck with entering the code manually.
There are 4 ways of re-encoding Cyfral and 2 ways of re-encoding metakom keys.
Cyfral 1: 01 C2 C1 01 00 00 00 CR
Cyfral 2, 3, 4: unknown. Cyfral 2 is likely 01 C1 C2 01 00 00 00 CR

Metakom 1: 01 C4 C3 C2 C1 00 00 CR
Metakom 2: 01 C1 C2 C3 C4 00 00 CR

1 Like
What blank key models can be written with Flipper?
#4

Thanks for the info !!!

#5

If you’re curious, I figured out Cyfral-3 reencoding.

I suppose you already know that Cyfral gets encoded in quarternary: 0b1110 for 0, 0b1101 for 1, 0b1011 for 2, 0b0111 for 3. Cyfral-3 basically encodes them for powers of 2 and inversed.

An example is 22D9 1110 1011 1110 1011 0111 1101 1011 1101 - C3 supposedly gives 82822414, key word supposedly because 0111 ≠ 1011…

Screenshot_2022-12-30-12-03-49-70_f9ee0578fe1cc94de7482bd41accb329
Screenshot_2022-12-30-12-03-49-70_f9ee0578fe1cc94de7482bd41accb3292400×1080 151 KB

#6

Thanks for sharinh this info !!!

#7

Anyone know if it’s been updated for this? I could really use it as the mega touch I have uses this key and apparently they are only good for 10 years and then die so I really want to back it up!

#8

DS1996 support got added. Writing 36 bit keys… no. :stuck_out_tongue:

#9

Oh that’s sucks… I was able to read the key from the megatouch but it wouldn’t write it that’s for sure. I wish there was a way… I’m running out of time unfortunately….

#10

When was DS1996 Support added? Do you mean to the official firmware or to something else?

#11

Account made 11 minutes ago… okay, you do you.

Yes, of course OFW, CFW devs don’t care about things that exist only in Russia. Maybe those Schlage locks but I don’t know.

#12

Yeah new account… got my flipper zero maybe a month ago, messed around a bit, mostly interacted on Reddit. Saw this post addressing an issue I’ve had and asked a question.

Just updated my flipper zero but still no success with a Schlage iButton lock. If I read it, it does come up as Dallas 1996, but I can’t emulate it to work with the lock. Also can’t write it to a writeable iButton- even though I’ve been able to write Dallas1990 to those same buttons.

Is there more to the Schlage protocol or am I doing something wrong?

#13

I’m not sure what could be so special in Schlage locks as I have a solid 0 of them here in Russia. And the implementation of DS1996 emulation is near 100%.

Now for that NEAR… if a flipper emulates a DS1996, it does not support writing memory. It’s read only. Which makes my suggestion:

Read your iButton, and save the read. Then, unlock your door. Then read again, and look for differences.

As for writing it, there are no blanks you can use. In 2009 iKey sold a “DS1996RW” for 550 rubles, except that is now long gone (and real DS1996s cost 2750 from them now. oops). AND writing to an RW1990 is useless because the DS1996 has 8KBytes of memory whereas the 1990 does not

#14

Ah okay, I see. I’ll do what you said and see if there are differences when I read after unlocking the door and let you know what I see…

#15

Flipper shouldn’t even suggest writing DS1996 to a blank: it only does it for 1990 and 1992, and the latter is broken.

AFAIK they still didn’t fix a general problem of ignoring a reset mid-command, and (at least) some DS1990 readers seem to test it as an anti-emulation measure.

#16

Going to look into this. I’ve got a DS1996L-F5+ 64kb iButton that I ordered online. I’ve got two keys that are of the same markings from what I can decipher, and one schlage lock.

So far what I have figured out is that:

  1. Both keys have roughly the same data structure inside, minus ~20 bytes difference at least as read from the flippers reader, I have not read the entire 19 page spec about the memory that is factory burned (will update in future post)
  2. The data inside of the key does not change once the key succesfully unlocks the door (meaning that the file read from the key returns nothing when the command diff in terminal is applied to the file from before and after unlocking the door)
  3. The lock is preventing either 1. the contacts of the flipper from making a solid connection or 2. emulating the signal correctly
    additional info - the physical body of the lock is preventing the contacts of the flipper I believe. I can’t really tell, but the objective is to replace the key with the flipper, so if it physically doesn’t touch the contacts emulation is out of the question.
  4. I have tried using the flipper to write a key, read that key, and compare that to the working key. I do notice that there is a difference in the two binary files as read from the flipper.
#17

It is likely critical. Factory ROM includes serial number, commonly used for access control in all kinds of systems (DS1990, some with Mifare Classic, almost all with LF RFID, etc.)

You can plug a couple of wires into GPIO GND and 1W, and then side of reader is GND, center is 1W.

1 Like
#18

It is likely critical. Factory ROM includes serial number, commonly used for access control in all kinds of systems (DS1990, some with Mifare Classic, almost all with LF RFID, etc.)

That’s tough :confused: I had assumed that to be the case but was optimistic.

You can plug a couple of wires into GPIO GND and 1W , and then side of reader is GND , center is 1W .

Will let you know what I find with this… I have also figured out that the particular lock I am attempting to emulate a key for requires a H10310 RFID signal to complete the authorization with the lock.

My goal is to find a writeable tag that will allow me to reproduce this signal, and hopefully, if this GPIO solution will satisfy the lock, maybe I will create a sort of “hat” for the flipper that can easily do so, since this is an attempt to replace an item I carry around each day with me. Not so sure how this will play with my external sub-ghz antenna but beggars cannot choose

@maqumih is there anything as far as insight goes that you could provide as far as potential anti-emulation features of these locks?

Also, more experience flipper devs, is there any way that if I can emulate this DS1996 signal, I could also emulate RFID at the same time?

Thanks so much for your help to this point, I’ve gotten farther today than I have in the last two weeks on my own

#19

Flipper should be able to read, write and emulate it just fine.
But this kind of cross-band is new to me. Is it from your research, or from public documentation?

Flipper writes only on T5577. It should be compatible.
Blanks for DS1996… Don’t know of any.
If you erase the memory (back it up beforehand, obviously), does the lock open? If so, DS1990 blank may suffice. Otherwise, I’ll really carefully say TM2004, but it has EEPROM < 64k.

1W and GND are the rightmost pins, so with a fair chance (no idea which exactly module do you have) it won’t interfer.

Only general. Interrupting power to see whether the tag was reset. Sending T5577/EM4305/other blanks’ commands. Working on abnormal frequencies. AFAIK, Flipper resists the first two for RFID and the second for iButton.

Not with existing software. But should be doable.

Motorola Advanced System Key hacking help