Ultimate UHD Drives Flashing Guide Updated 2025

[redmarple]

Should I flash it to 3.10 MK?

Code: Select all

Drive Information
OS device name: D:
Current profile: BD-ROM
Manufacturer: ASUS
Product: BW-16D1HT
Revision: 3.01
Serial number: [redacted]
Firmware date: 2117-03-31 14:26
Bus encryption flags: 1F
Highest AACS version: 81

LibreDrive Information
Status: Enabled
Drive platform: MT1959
Firmware type: Original (unpatched)
Firmware version: 3.01
DVD all regions: Yes
BD raw data read: Yes
BD raw metadata read: Yes
Unrestricted read speed: Yes

[zittrig]

3.10MK (with sleep bug) or WH16NS60 1.02MK (without sleep bug).

[redmarple]

3.10MK (with sleep bug) or WH16NS60 1.02MK (without sleep bug).

Thank you. But why should I upgrade. Do I gain anything? Drive copies 4k discs.

[zittrig]

I've learned that the 3.10MK or the WH16NS60 1.02MK rips faster if the disc are clean or has minimal surface issues like scratches e.g.. But there could be problems mit some 3-layer discs.

For "problem discs" the ASUS 3.02 or the LG BH16NS60 1.02 can be used 'cause they read longer with slow speed to get the datas.

But test it and decide by yourself.

[redmarple]

I've learned that the 3.10MK or the WH16NS60 1.02MK rips faster if the disc are clean or has minimal surface issues like scratches e.g.. Also could there be problems mit some 3-layer discs.

For "problem discs" the ASUS 3.02 or the LG BH16NS60 1.02 can be used 'cause they read longer with slow speed to get the datas.

But test it and decide by yourself.

I cannot make mistakes when flashing the correct firmware?
The firmware pack has only 3.03 and 3.10 and I have 3.01 which I can backup to disk. Where can I get 3.02?
BH16NS60 has 1.02 and 1.01 and 1.03 in the pack.

[zittrig]

Another support you can find right here in this topic in the first post.

Look for recommended firmware title and sleep bug. And there can be found two firmware packs. The all you need firmware pack and the MK firmware pack. The second contains some more older firmware versions also.

[MartyMcNuts]

I've learned that the 3.10MK or the WH16NS60 1.02MK rips faster if the disc are clean or has minimal surface issues like scratches e.g.. Also could there be problems mit some 3-layer discs.

For "problem discs" the ASUS 3.02 or the LG BH16NS60 1.02 can be used 'cause they read longer with slow speed to get the datas.

But test it and decide by yourself.

I cannot make mistakes when flashing the correct firmware?
The firmware pack has only 3.03 and 3.10 and I have 3.01 which I can backup to disk. Where can I get 3.02?
BH16NS60 has 1.02 and 1.01 and 1.03 in the pack.

I think my firmware pack has the BW-16D1HT 3.02 firmware in it. Go to the SDFtool Flasher thread, first post.

[csdesigns]

This Guide Is Made By: Billy/Billycar11, MartyMcNuts, Blackened2687, Coopervid, d00zah, mike admin, SamuriHL, st4evr, TeddyRaspin, Woodstock, Bluntman, Alex/jonghotti, garygomm
Even if they didn't contribute directly i have used their information

Huge props and thanks goes out to everyone involved to make this possible. Just wanted to report my recent success with the BU40N I purchased last week. Drive arrived with the following fw:

Code: Select all

Drive Information
Manufacturer: HL-DT-ST
Product: BD-RE BU40N
Revision: FR07
Firmware date: 2118-01-22 15:36
Bus encryption flags: 1F

LibreDrive Information
Status: Possible (with patched firmware)
Drive platform: MT1959
Harware support: Yes
Firmware support: No
Firmware type: Original (patched version available)
Firmware version: 0.FRO7J
DVD all regions: Possible (with patched firmware)
BD raw data read: Possible (with patched firmware)
BD raw metadata read: Possible (with patched firmware)
Unrestricted read speed: Possible (with patched firmware)

I was able to easily update to the 1.03 fw following Billycar11's detailed guide:

Code: Select all

Drive Information
Manufacturer: 
HL-DT-ST
Product: BD-RE BU40N

Revision: 1.03
Firmware date: 2118-10-24 19:34

Bus encryption flags: 17

Highest AACS version: 77



LibreDrive Information
Status: Enabled

Drive platform: MT1959

Firmware type: Patched (microcode access re-enabled)

Firmware version: 1.03

DVD all regions: Yes

BD raw data read: Yes

BD raw metadata read: Yes

Unrestricted read speed: Yes

FYI, I installed the drive into my trusty old Sonnet Echo 15+ Thunderbolt 2 dock connected to a Mac Pro 6,1 (running Monterey 12.7.6) and flashed from there. Some slight modifications were performed to properly fit the drive into this enclosure since the BU40N is considerably slimmer than the previous existing drive (HL-DT-ST CT30F). Basically, just some 3M double-sided tape and rubber spacer rings were required to ensure the drive is balanced, as only one screw mount point aligned from the original included cage.

Code: Select all

Echo 15 TB2:

  Vendor Name:	Sonnet Technologies, Inc.
  Device Name:	Echo 15 TB2
  Mode:	Thunderbolt 2
  Device ID:	0xC
  Vendor ID:	0x8
  Device Revision:	0x1
  Route String:	3
  Firmware Version:	25.2
  Port (Upstream):
  Status:	Device connected
  Link Status:	0x2
  Speed:	Up to 20 Gb/s x1
  Current Link Width:	0x2
  Cable Firmware Version:	0.1.23
  Link Controller Firmware Version:	0.14.0
  Port:
  Status:	No device connected
  Link Status:	0x7
  Speed:	Up to 20 Gb/s x1
  Current Link Width:	0x1
  Link Controller Firmware Version:	0.14.0

Code: Select all

HL-DT-ST BD-RE BU40N:

  Firmware Revision:	1.03
  Interconnect:	USB
  Burn Support:	Yes (Generic Drive Support)
  Profile Path:	None
  Cache:	4064 KB
  Reads DVD:	Yes
  CD-Write:	-R, -RW
  DVD-Write:	-R, -R DL, -RAM, -RW, +R, +R DL, +RW
  BD-Write:	-R, -RE
  Write Strategies:	CD-TAO, CD-SAO, CD-Raw, DVD-DAO
  Media:	To show the available burn speeds, insert a disc and choose File > Refresh Information

Ripped 4x UHD BDs last night, with max speeds writing to internal dual-SSD RAID0 of the dock at 6x speed.

[jjmkv]

Slightly nervous about having an app making and pulling files from a Russian server as obv there is a reputation associated with servers hosted in certain country’s which is why I went with pulling a public keydb file myself manually and vetting the file. Would prefer to do that each time. I followed a guide on here on how to add the keydb file I assume that’s still supported option. Any ideas on how you submit to the public keydb file? Cheers

We have all been using MakeMKV's SDF file for years without any issues, no matter where it has been hosted. Do you really think the software would be so widely used if it was routinely infecting people's computers?

Each to their own though. Grab the dump file that MakeMKV creates, send it to the relevant MakeMKV email address and create a post with the details of the film and the dump file. You can also attach the dump file to the post and one of the folks who help maintain the public KeyDB will grab it and add the key.

It's great that MakeMKV and its SDF download has been reliable for many years. However, relying solely on past experience or wide availability are not foolproof cybersecurity strategies (In fact the greater install base the more attractive it is to bad actors). Threats, such as supply chain attacks, are becoming more common and sophisticated, posing risks to even well-regarded software. Unfortunately, servers and communications originating from certain regions can also present higher risks of these attacks.

Perhaps my background in secops has heightened my awareness of these risks, but it doesn't hurt to stay vigilant and proactive in protecting yourself. A good example is Notepad++, where the update process was hijacked to distribute malicious installers of the StrongPity malware. Similarly, there are numerous documented cases of supply chain attacks in GitHub repositories. The Notepad++ and most of the GitHub supply chain attacks didn't involve the creators or maintainers of the software, so trusting them and their past work would have provided false reassurance in those cases.

For my own use, I prefer the zero trust strategy, anything that’s been downloaded from the internet gets throughly vetted first before using them, no auto updates etc. If others prefer automatic updates and are comfortable doing that, that's their choice. However, I don't mind the small inconvenience of manually obtaining files from time to time and doing my own checks—after all, better safe than sorry.

I appreciate your advice on sending the dump to the email. Cheers!

Beyond the scope of this particular thread, but definitely something that warrants discussion imo. Having to download anything from russia, regardless of how long it has worked without issue, seems like an odd choice. Whats the reasoning behind that? Is it just a matter of those keydbs needing to be hosted somewhere like that legally?