I harvested the PCB from an old 3320 and stuck it in the 3321 chassis with the 3321 reader/faceplate sure enough all the tags that would not work before suddenly worked.
This confirms the reader itself supports NTAGs just fine even on newer models. It is the mainboard PCB on the door side or firmware on it for sure.
I can’t confirm firmware versions and the chips are covered in epoxy which is a pain… however comparing the boards side by side I noticed they are identical with one exception: the old one has two pairs of diodes populated and the new one leaves them unpopulated.
I am wondering if this is not firmware at all, but someone cutting corners and someone in QA only checking it still worked with the samsung mifare classics and not bothering to test anything else.
It will be a couple months before I am done moving in and can setup my EE lab again, but if anyone with a non working unit laying around wants to populate those 4 pads with diodes it would be worth trying.
Else I’ll get to it myself and report back eventually. Just figured I would share my terrible workaround and the potential implications
Did you happen to get to this? I’ve got a “bricked” 3321 and an Elec Lab to do it (depending on the conformal coating), and maybe even some spare time over the uni break!
Where do I go looking for those 4 pads, and what orientation are the diodes in on the board that works?
What are the odds that they’re just anti-flyback protection QC decided wouldn’t kill it until after the warranty expired?
Has anyone managed to dump the firmware of a working unit btw? I’ll have a crack at this while I’ve got mine off the door to work out if its possible and how but that firmware won’t actually be useful
Hey folks, bringing back this old thread to say that I bought the same deadbolt unit which came today. It is not accepting my xSIID implant as an acceptable code, despite scanning the included Samsung brand cards just fine. It seems to detect my implant just fine- when I try to register it, it gives me one “beep” as if to acknowledge the scan, followed by the four-tone “ding dong ding dong” which is the error message.
I’ll just be returning it since I don’t care to pay $180 to carry around a different key instead of my regular house key. @amal, can this be used to update the Chip Compatibility Matrix? There’s no info listed for the intersection of the xSIID and any of the Samsung deadbolts, old or new model.
thanks! I’ll look into the first method and consider doing it if I can get the parts here and do it all before the return window closes on my samsung lock. I’ll get back to you soon I hope!
Hey Pilgrimsmaster, is that second solution something I can do to my xSIID chip with permanently altering it? I didn’t think that Mifare was something related to this chip. I’m not super familiar with the technologies outside of the ones used for the xSIID and even then I’m not knowledgeable about the technical stuff.
Hey Amal,
I’m very good with embedded systems, but what you’re trying to do isn’t possible. First, if one can read the firmware of some system(and that’s a big IF) it is compiled and a disassembler is required to get some assembler code. It would take very long time to reverse engineer the functionality of the device with this method.
The best would be to use the hardware from the SAMSUNG lock and make a new controller for it on which you can put your own firmware. If you would make this firmware open source SAMSUNG probably will hate you for it. It’s like the guy’s did with the DD-WRT Firmware for routers.
However, I love SAMSUNG, everything in my house is SAMSUNG(washer, dryer, stove, computer and all phones). I will buy one of those locks and try to make it work and let you know the outcome.
But has anyone tried to reach out not to “Samsung” but the actual code gremlins,
Might be easier to convince the people actually working on the product to re enable it in current firmware, than some random Samsung customer support who’s never even seen the lock
and in our products, it’s encrypted too - because we have strong suspicions that our products have been reverse-engineered in the past.
If it’s not encrypted though, disassembling a firmware is nothing tricky. It’s just long and tedious if it wasn’t made with a standard compiler. If it was however, many disassemblers will be able to put something ressembling the original source code back together. If you’re really lucky, some of the original symbols will even be left in the compiled code
The link above is the firmware samsung shs3321 lock, so that big if is sorted
The board has got a programing header and the micro has no fuses set. If your interested in decompiling the firmware I dumped or writing your own system for the PIC18 micro, that post is probably a good place to start.
Good news!! It’s not encrypted!!
I’ve added the disassembly of both the new(Broken) version and the old (works with NeXT) firmware dumps to the git repo. PIC18 assembly isn’t in my wheelhouse, but maybe that’ll be helpful to someone else?
These were made using the MPLAB X IDE just importing the hex dump as a new project.
@TamablePumpkin thanks again for the info, the TRH031M is the NFC reader and it’s obsolete, I guess the newer version of the 3321 has a different chip for that.
I had a quick glance at the assembler code and found some added functionality and something what looks like code optimization(but that’s not sure). It looks like SAMSUNG added a software filter for the NFC tags which allows the blocking of everything but their cards.
It would take quite some time to reverse engineer the functionality from the assembler code which is probably not worth the effort.
The PCB seems to be a 2-layer board which would simplify things somewhat. I added the board overlay picture where the front and the back is together.
I kind of go with the idea to make a new controller using the CR95HF from STMicroelectronics and maybe a ESP32 or a nRF52840 from NORDIC as MCU, this would give me WiFi or Bluetooth.
at least, Standby…
