Re: Crackare Vodafone Station Firmware
Muredac Boule
Luckily, Nordic also provides firmware for their dongle to be used as a ZigBee sniffer. I loaded that up on another dongle, and started listening for my packets. Nothing. It took a bit of debugging, but I finally figured out that I had misread a sentence in the nRF52840 doc. After making a fix, the sniffer saw my packets. Sending them very rapidly and turning the tag on did indeed produce a message from the tag that it found my "base station" at an RSSI of -50. Sweet. It was time to analyze the protocol, but then I saw something that immediately cooled my enthusiasm. The stock code that speaks to the display forced it into a 1bpp use - black and white, no greyscales! No good!
My wishes were simple - a wire-free picture frame that can be updated remotely. I designed the firmware and protocol around this. First, I designed a storage system for settings that wear-levels across some large amount of flash, so as to not kill flash prematurely (it has a limited number of write cycles, you know). Then, I designed a simple (but extensible) protocol for the tags to talk to the base station (which is still an nRF52840 dongle). The protocol also looks like 802.15.4 since that is what the Marvell radio supports/expects/can filter addresses on.
When a tag is erased, or newly flashed, it begins by attempting to associate with a master. It does so by sending out a broadcast association request at a very low transmit power on every channel, in turn. The request contains tag information, like hardware type, battery level, and screen size/type/resolution. The master who receives this request may choose to accept it. If the tag gets a positive and valid response of at least a given signal strength, it will accept it. The signal strength limits make it just a bit harder to pair with someone else's tags. The thresholds chosen require the tag to be basically right on top of the base station to pair successfully. As both sides check for signal strength, being evil and pretending to be close would be difficult without a very very large transmitter. The pairing response packet contains some configuration data for the tag. Some info is also assumed, for example the channel number where the response was received is saved and from then on used to communciate with the master. The most important thing in the response itself is the parameter telling the tag how often to check in. This will literally determine how often the tag will wake up and report back to the master. Setting this high improves battery life, as sleep may last longer. Setting this low improves responsiveness, since no image uploads may happen until the tag checks in. For once-daily updated tags I chose 1 hour check-in period. This parameter, however, is configured in the station firmware and is up to you to change as you see fit. A couple of other check-in-related parameters are supplied at association time. They are: the number of failed check-ins needed to blank the screen and the number of failed check-ins needed to disassociate from this master. Either or both can be zero to disable such functionality. The idea is simple. If you do not update the tag images often, how will you know that they are still communicating properly? Well, you could check the base station's logs, but I wanted a more visible notification. If the "number of failed check-ins needed to blank the screen" setting is used, and that number of check-ins in a row fail, the screen will change to a "TOO LONG WITHOUT CHECK IN" message. It will revert back to the last image if a checkin succeeds. The second parameter is a convenience. As these tags lack any sort of convenient user input, I wanted at least some way to erase them to pair them to a new master. This is how! After this many failed check-ins, the tag will erase all association info and go back to its unpaired state, ready to pair again. The association response packet also contains the encryption key the master has provisioned. It is saved and will be used from then on to secure communications.
802.15.4 uses the same spectrum as WiFi/Bluetooth/microwaves/etc... Needless to say, frequency selection is crucial. At my house, zigbee channel 20 was the most free, so I used that one. About 99% of packets make it across the house error free. By comparison, channel 11 only allows 80% of packets to pass through. Station's channel is configured in the station firmware.
The protocol has a version field, provided at association time, so that the base station knows what "language" the tags speak. And all the packets have a few bytes reserved and required to be zero for now. This allows for very easy extensibility in the future, by simply reusing these bytes to mean something. This is safe as we know that any old firmware will set them to zero and will not read them. Extensibility for the win!
This tag had a radio incapable of QPSK at 2.4GHz, so a new radio layer was needed. I decided to reuse the same protocol, just on another frequency and with another modulation. I went with the 915MHz band, and made sure the bandwidth was wide enough (more than 500KHz) to legally permit for any transmit power I wanted. GFSK modulation is used and 250Kbps is the selected data rate. I implemented a TI cc1101 driver in the firmware of the base station, and wired "radio index" through all the code in the station to support multiple radios. It took only a day, and it works beautifully! Actually wiring the second radio to the nRF52840 stick was quite easy - the photo earlier in this article shows how it looks and the source code for the base station has the wiring connections in tiRadio.c
Well, here it it, what you came here for. The license is simple: This code/data/waveforms are free for use in hobby and other non-commercial products. For commercial use, contact me. The downloads include the source code for my firmware for the Samsung/SoluM 4.2 inch black and white tags, the source code for the bmp2grays program, the source code for my custom firmware for the Chroma/ZBD device, and the source code for the base station to allow all of them to be used and updated. I am also including binaries, in case are too lazy to build the code yourself. [DOWNLOAD HERE]. Update (jul 2022): here is newer 8051 code that also has a nicer build system. See Makefile for how to use. LINK.
Ciao, ho un vodafone station e sono terribilmente incavolato con vodafone per tutti i blocchi che ha messo...la tua spiegazione sembra molto semplice ma da quello che ho capito la cosa era più complessa da fare...inoltre mi sembrava avessero inibito la modalità aggiornamento..
- Page: Auto Provisioning
- Page: Check the installed firmware version
- Page: DECT Troubleshooting How-to
- Page: Determining the IP address of your DECT M-SC-Series base
- Page: Entering Snom Deskphone Web Interface - WUI
- Page: Entering Web Interface - WUI of your Snom DECT-M-SC Series Base
- Page: Get the snom phone ready for operation
- Page: How can I backup and restore the phone configuration
- Page: How can I configure a second hand Snom device that still points to the old PBX because of a redirection
- Page: How can I obtain a SIP trace from the phone
- Page: How can I trigger a settings sync on a DECT M300,M700,M900
- Page: How to - Core Dump
- Page: How to auto upgrade firmware on M500, M55, M58
- Page: How to capture large or permanent PCAP traces
- Page: How to check which firmware version is currently installed on M500, M55, M58
- Page: How to deal with defective products
- Page: How to do a Handset reset - M90, M80, M70, M85, M65, M25
- Page: How to Do an Firmware Update using an USB-Stick
- Page: How to enable early logs on desk phones
- Page: How to enter M300, M700, M900 - Web Interface
- Page: How to factory reset the M200-SC , M215-SC
- Page: How to factory reset the M300,M700,M900
- Page: How to get a Log from the DECT base
- Page: How to manually upgrade firmware on M500, M55, M58
- Page: How to migrate to version 10.1.x
- Page: How to obtain a log from a desktop phone
- Page: How to obtain a SIP trace from a deskphone
- Page: How to rebuild the DECT tree after a base station removal or failure
- Page: How to Register a M15-SC to the M200-SC
- Page: How to retrieve the device Serial Number, MAC address and Hardware Revision Number of a DECT M-Series Device
- Page: How to set up auto provisioning on M500, M55, M58
- Page: How to setup a Syslog server on a Desktop phone
- Page: How to setup SPLiT - VoIP Test Environment
- Page: How to store a PCAP trace into an USB mass-storage device
- Page: How to store a phone syslog into an USB mass-storage device
- Page: How to store a SIP trace into an USB mass-storage device
- Page: How to submit a support request on Snom Helpdesk
- Page: How to update M-Series - DECT handsets
- Page: How to update M300,M700,M900 DECT Base Station manually
- Page: How to update M300,M700,M900 and handsets via Network
- Page: How to update your firmware manually
- Page: How to upgrade M400 from 610.3 (out-of-the-box) to 650.2
- Page: How to use a Syslog Server with the DECT base M300,M700,M900
- Page: Howto update the Firmware manually on a D8xx Series Deskphone
- Page: Incoming calls are rejected by "403 Use Proxy"
- Page: Is my Snom phone still covered by warranty
- Page: LDAP stopped working after upgrade from Fw v8.x to v10.x
- Page: My phone displays the SIP Disabled - error, how can I fix it
- Page: Reboot your Snom Phone
- Page: Rescue Mode on D-series desk phones