For me, it’s really the exception that proves the rule: I love every cheese I’ve ever tried, but I hate Emmentaler, especially when it has little holes and tricks you into being something else
NOTE: This entire hack and this post were made together with ChatGPT. I did the actual testing on my Honeywell doorbell; ChatGPT helped reverse engineer it and generated the PowerShell scripts.
I have a Honeywell Home Series 9 wireless MP3 doorbell and wanted to get rid of the built-in factory ringtones as quickly as possible.
The normal USB drive only shows your custom MP3 files. The factory sounds are hidden.
Turns out my Honeywell uses a Jieli BR25 controller:
VID:PID: 4C4A:4155
Product: UACDemoV1.0
Disk: BR25 UDISK
Windows reports a 13,910,016-byte USB disk, but the BR25 actually responds to SCSI READ(10) up to a 16 MiB boundary.
The hidden area is:
LBA 27168–32767
2,867,200 bytes
Inside it I found a Jieli/JLFS "tone" filesystem containing:
index.idx
01.mp3
02.mp3
...
15.mp3
These are the actual Honeywell factory chimes.
I extracted them and then tested changing the JLFS entry for 02.mp3 so it pointed to the audio data of 01.mp3.
After rebooting (remove batteries):
factory ringtone 1 == factory ringtone 2
So that proved it.
I then changed 02.mp3 through 15.mp3 to all point to 01.mp3.
Final result, all factory ringtones are the same.
Tried to delete all but one, didn't succeed.
My own custom MP3 files still work normally.
So the Honeywell still technically has 15 factory ringtone positions, but all the unwanted factory sounds are effectively gone.
No opening the doorbell.
No soldering.
No flash programmer.
No JTAG/UART.
Just USB + PowerShell + SCSI READ(10)/WRITE(10).
IMPORTANT:
Do NOT blindly write my LBAs to your doorbell.
First verify that yours is also:
Honeywell Series 9 / RDWL917 / RDWL917A / DC917 / DC917NG
BR25 UDISK
VID_4C4A PID_4155
Then:
Read SCSI capacity.
Check whether LBAs 27168–32767 are readable.
Dump that hidden area.
Look for "tone", "index.idx", "01.mp3", "02.mp3", etc.
Make a complete backup.
Verify the JLFS CRCs.
Patch the FILE ENTRIES, not the actual MP3 audio.
Write only the changed 512-byte sectors.
Immediately read them back and verify them byte-for-byte.
Power-cycle the doorbell.
One thing that did NOT work:
We tried changing index.idx from 15 tones to 1. The Honeywell ignored it.
We also tried marking 01.mp3 as the final JLFS directory entry. That made the doorbell completely silent. Restoring the original sector fixed it.
So the working solution is simply:
02.mp3 -> data of 01.mp3
03.mp3 -> data of 01.mp3
...
15.mp3 -> data of 01.mp3
If anyone else has a Honeywell Series 9 MP3 doorbell, I'd love to know if your hidden storage layout is identical.
Search keywords for anyone finding this later:
Honeywell Series 9 hack
Honeywell Series 9 factory ringtone removal
Honeywell Series 9 delete default ringtones
Honeywell Series 9 hidden MP3
Honeywell Series 9 custom chime
Honeywell Series 9 BR25
Honeywell BR25 UDISK
Jieli BR25 doorbell
BR25 UDISK hidden storage
VID_4C4A PID_4155
4C4A:4155
UACDemoV1.0
Jieli JLFS tone
Honeywell RDWL917 hack
Honeywell RDWL917A hack
Honeywell DC917 hack
Honeywell DC917NG hack
If there's interest, I can clean up the PowerShell scripts and post the read-only dumper, backup tool and guarded patcher.
Mine is cooked, almost all of the pins gone. Can only charge slowly with chargers fixed In very particular angles.
​
Had to order the elite while waiting for the communicator because this will not last for another 6 months, but now have to wait till August...
​
So did anyone replace the USB port?