• AnyStream is having some DRM issues currently, Netflix is not available in HD for the time being.
    Situations like this will always happen with AnyStream: streaming providers are continuously improving their countermeasures while we try to catch up, it's an ongoing cat-and-mouse game. Please be patient and don't flood our support or forum with requests, we are working on it 24/7 to get it resolved. Thank you.

Converting UHD Friendly drive into UHD Real and viceversa

Status
Not open for further replies.
  • Select hex range from 0x1E0000 to 0x1E84FF and copy it from the dumped firmware to the new firmware file.
  • Select now the hex range from 0x1E9000 to 0x1EBFFF from the dumped firmware to the new firmware file.
  • Select, at last, the range from 0x1F0000 to the end from the dumped firmware to the new firmware file.


Hi TeddyRaspin,
I am reading the past 3 days about this topic and start to understand better and better.

If I compare, it seams the difference are is more code in the first step copied to the clean firmware. Can You explain what is there (Decryption-Keys?)? The rest stays the same.

  • On the backup firmware (the dumped one) select hex range starting from 0x1E8000 offset to 0x1E84FF and copy it in the same range of the new firmware. (**)
  • Do the same as point 3. but starting now from 0x1E9000 to 0x1EBFFF. (***)
  • At last, copy range from 0x1F0000 to the end. (***)

Is it possible that You or Blackened2687 built anorher tool like EEPROM_DATA_MOVER.EXE for this conversion? :thankyou:

I have the BH16NS55 1.02 now or 3.02 BW-16D1HT friendly firmwares from originally 1.03 LG BH16NS55 SVC 55.

Do I need now a clean LG WH16NS60 firmware?

Would You be so kind to provide one. Thanks.
 
The upper posts posts on this page might be worth reading:








---

@Red_User
So maybe you need a BU30N firmware, difficult to find.

In any case make sure you DON'T flash any Clean firmware into the unit, the Clean firmwares don't contain any drv drive signature.
The clean firmware must be modded, some data of the original unit's dump needs to be imported into the Clean firmware, before flashing into the unit's EEPROM with Dosflash.
The drv value is uinque (principially) to each sample unit for UHD support.

Make sure to make several backups of your original BU40N dump on multiple places!!

EEPROM data mover is probably not compatible to BU40N firmwares, but anyway no issue when you use hexeditor (when using correct offsets and ranges).


Did you use the hexrange from this guide here?
=>https://forum.redfox.bz/threads/converting-uhd-friendly-drive-into-uhd-real-and-viceversa.74544/
(The first hex range differs, the difference is marked in fat letters)
Select hex range from 0x1E0000 to 0x1E84FF and copy it from the dumped firmware to the new firmware file.
Select now the hex range from 0x1E9000 to 0x1EBFFF from the dumped firmware to the new firmware file.
Select, at last, the range from 0x1F0000 to the end from the dumped firmware to the new firmware file.

----
Or did you use this hex range from other guide?
https://forum.redfox.bz/threads/dumping-downgrading-firmware-on-uhd-friendly-devices.74479/
(The first hex range differs, the difference is marked in fat letters)
Steps for importing data from backup firmwares : (Hex Editing)
On the backup firmware (the dumped one) select hex range starting from 0x1E8000 offset to 0x1E84FF and copy it in the same range of the new firmware. (**)
Do the same as point 3. but starting now from 0x1E9000 to 0x1EBFFF
At last, copy range from 0x1F0000 to the end. (***)


Afaik the EEPROM data mover (always) uses the hexrange 0x1E8000 offset to 0x1E84FF from the latter guide. (But I didn't check this entirely, see own tests further below)
I tested with EEPROM data mover on a WH16NS60 (UHD real drive). It even accepts firmware 1.01 dump from a WH16NS60 UHD-official-drive.
(first EEPROM mover dialog is for the original firmware dump, the 2nd dialog to choose the Clean firmware to where to import into.)
--

Anyway the EEPROM data mover seems to be doing something different things with UHD real drive firmwares.

Tested both Teddys guides on just (experimeting) "mods" with EEPROM data mover from a WH16NS60 original firmware into a Asus BW-16D1HT firmware, and from WH16NS60 original dump into BH16NS55 clean firmware seperately

(of course I recopied the unmodified Clean firmware when trying both guides one by one)

The resulting file NEITHER matched to the comparison file using "dd" and hexeding range from to the first guide: https://forum.redfox.bz/threads/converting-uhd-friendly-drive-into-uhd-real-and-viceversa.74544/
NOR to "dd" using the hexrange from this guide: one https://forum.redfox.bz/threads/dumping-downgrading-firmware-on-uhd-friendly-devices.74479/
??

So I had expect the EEPROM data mover should at least (just) match to the dd-result using the hexrange from this guide:
https://forum.redfox.bz/threads/dum...ading-firmware-on-uhd-friendly-devices.74479/

just as an expriment if EEPROM data mover behaves unusual:
Result a (completely) different behavior, but can't say what it exactly is.

I double controlled, and I used the same seek=, skip= and count= parameters from a few month before stored in a text file seperately, which got same result with EEPROM data mover on a (normal BH16NS55 UHD-friendly drive) from 1.03 to 1.02 (or 1.01) downgrade.
So a bit odd??:confused:

And I rechecked everything in calculator, redone clean firmware unzipping, both guides steps etc, always with test-copies of all elements needed, or course. :)


Hi Oschi;)

Great investigation so far, would be great for the comunity if we had source code for all the tools here, or some description at least from the programmers.
Do You know how I get from my BH16NS55 1.02 or BW-16D1HT 3.02 former BH16NS55 1.03 to the WH16NS60 Real UHD firmware? Can I use the EEPROM-DATA_MOVER in a clean WH16NS60 firmware? Do You have a clean one? or provide Your WH16NS60 original dump file?

Thank You
 
You don't, you'll criple the drive. The NS60 is an official drive and has hardware on board (aacs 2 certificate) the ns55 doesn't. Why would you want to turn a friendly drive into a non-friendly official one anyway?

Verstuurd vanaf mijn Nexus 6P met Tapatalk
 
I've successfully converted any ASUS/LG UHD Friendly drive, based on MediaTek chipset MT1959 to a real UHD Drive (WH16NS60) !!! and viceversa.

If you own a WH16NS60 you can flash it and convert it as a BH16NS55, for example, which is UHD friendly.

Of course, while AnyDVD can successfully handle UHD friendly drive, if you have the WH16NS60 firmware onboard, it will not be able to retrieve AGID and it will not work (i.e. it won't decrypt any UHD disc).

ou don't, you'll criple the drive. The NS60 is an official drive and has hardware on board (aacs 2 certificate) the ns55 doesn't. Why would you want to turn a friendly drive into a non-friendly official one anyway?


Perhaps You should look at the thread topic or my quotes.

Reasons?
I could watch a movie completly with legal software without waiting for keys etc.
But for me the main reason is to experiment with this stuff, and learn thats all.
 
Oh I know what the topic is about. I just wouldn't do it or recommend it. Tricky to do, and you can criple the drive if you do something wrong. I'd just get an official drive from the start. Lot safer and less of a hassle.

Verstuurd vanaf mijn Nexus 6P met Tapatalk
 
Hi Oschi;)

Great investigation so far, would be great for the comunity if we had source code for all the tools here, or some description at least from the programmers.
Do You know how I get from my BH16NS55 1.02 or BW-16D1HT 3.02 former BH16NS55 1.03 to the WH16NS60 Real UHD firmware? Can I use the EEPROM-DATA_MOVER in a clean WH16NS60 firmware? Do You have a clean one? or provide Your WH16NS60 original dump file?

Thank You

Yes the WH16NS60 Clean firmware link (forum.cdrinfo.pl) is further below, afaik that's also the original page and from EEPROM data mover and maybe a main guide from origin.

BUT, First make a backup dump of your original unit's firmware and store that seperately on several storage devices. Some a few users didn't care enough right in time doing this and ended up with a bricked unit, that's why che3vr0n warned. And if I understood Teddy correctly he was partly disappointed, people didn't watch that original firmware-backup-dump matter described at the beginning of both of his guides:
firmware downgrade/crossflashing (wit UHD-friendly NS50 compatible firmwares);
&
UHD-official conversion and vice versa

Steps for dumping firmware : (DOS Method)

  1. Prepare an USB FreeDOS bootable stick, using Rufus (which can be downloaded here).
  2. Unzip on USB root the DOSFLASH.zip attached file.
  3. Enter into motherboard BIOS settings and set SATA Controller as IDE (or Legacy). If you can handle only AHCI, DOSFLASH will not properly work, or it could not work at all.
  4. Be sure to connect your ASUS/LG drive alone, as SATA Primary Master (USE SATA1 or SATA2 controller ports).
  5. Enable CSM (Compatibility Support Mode) and boot from the USB stick in Legacy Mode.
  6. At the command Prompt, type "DOSFLASH" and press Enter. If it does not detect anything, retype again. It could be needed to type DOSFLASH 3-4 times before ASUS/LG device be properly detected.
  7. It should show the Manufacter ID of your device, namely "MediaTek MT1959".
  8. Press the relative number of the detected device (1 in my case) and press "R" (without quotes) to dump eeprom firmware.
  9. Save firmware with the name you like and keep it safe.
---
After having original firmware-dump,+ stored safely:

https://forum.cdrinfo.pl/f29/dosflash-v2-0-patched-support-bh16ns40-bh16ns55-drives-96930/
LG WH16NS60 fw.1.00 Clean
=>https://www106.zippyshare.com/v/x0llCZ1c/file.html

Free Hexeditor for Windows "HxD"
https://mh-nexus.de/de/hxd/
=>https://mh-nexus.de/de/downloads.php?product=HxD20

I'd prefer the hexediting method in this case. So if Teddy is right with the hexrange for the UHD-friendly-to-UHD-official-conversion and vice-versa, as well, which I wouldn't doubt, I'd prefer this method,
as the EEPROM data mover seems to behave differently/strangely here.

Other members who found the manual hexediting-method more complex or just more time comsuming favored the EEPROM data mover method, said it would work even here, too.

After having original unit's firmware-dump, + stored safely seperately!!!
If you have question how to use the "HxD" -hexeditor (manual hexediting method); plase ask back.
--
Another way of manual hexediting method, is using "dd" in Linux, e.g. in Knoppix-Live-Linux-System).

After having original unit's firmware-dump, + stored safely seperately!!!

dd-hexediting-method (UHD-friendly to UHD-official-conversion)

First make a copy of your original-dumped firmware, and e.g. rename the copy to: LG_BH16NS55_Original_FW_1.0X_dumped_Dosflash_1.7_-Copy.bin

Make also a copy of WH16NS60 Clean-firmware "LG WH16NS60_1.00.bin" and rename it to
LG_WH16NS60_1.00_Clean_-Copy-edit.bin

dd-hexediting method
Boot Knoppix Live-Linux-System

After having original unit's firmware-dump, + stored safely seperately!!!

Type in a bash/shell/console/terminal/ as "root" in currently present directory with the Clean-firmware files and your original firmware-dump: If unsure how to get there: How to mount a filesystem on a specific partition, in Linux and how to navigate to a directory in command shell, please ask back.

Each commando alone confirmed with pressing return

"Select hex range from 0x1E0000 to 0x1E84FF and copy it from the dumped firmware to the new firmware file."
Code:
dd  if=LG_BH16NS55_Original_FW_1.0X_dumped_Dosflash_1.7_-Copy.bin  bs=1  skip=1966080  count=34048  of=LG_WH16NS60_1.00_Clean_-Copy-edit.bin  seek=1966080  conv=notrunc

-----

"Select now the hex range from 0x1E9000 to 0x1EBFFF from the dumped firmware to the new firmware file."
Code:
dd  if=LG_BH16NS55_Original_FW_1.0X_dumped_Dosflash_1.7_-Copy.bin  bs=1  skip=2002944  count=12288  of=LG_WH16NS60_1.00_Clean_-Copy-edit.bin  seek=2002944  conv=notrunc
---

"Select, at last, the range from 0x1F0000 to the end from the dumped firmware to the new firmware file."
Code:
dd  if=LG_BH16NS55_Original_FW_1.0X_dumped_Dosflash_1.7_-Copy.bin  bs=1  skip=2031616  of=LG_WH16NS60_1.00_Clean_-Copy-edit.bin  seek=2031616  conv=notrunc

The 3rd dd-commando for example doesn't read nor copy over any of the first count of 2031616 (decimal) Bytes ahead of the file. So ignores/skips the first Bytes 0 - 2031615 of the input- and output file.

And starts reading from (including) Byte-number 2031616 (decimal) to including Byte-nr. 2097151 (decimal) (=last Byte): counting from 0)...
from the input file...
and copies that range over to to (here to an already existing) Output-file, so (overwrites) the corresonding bytes in the output-file, starting from including offset 2031616 (decimal).

A count of 2031616 Bytes (0 <-> 2031615) are ahead of the included offset 2031616 (0x1F0000)
(counting strarting with 0)

The difference (in decimal) from whole count of 2097152 Bytes (0 <-> 2097151 / or 0x0 <-> 0x1FFFFF hex.dec.) and whole count of 2031616 Bytes (0 <-> 2031615 dec. / 0x0 <-> 0x1EFFFF hex-dec.)<=that are before offset 2031616 (=before 0x1F0000 in hex-dec.) is 65536 Bytes.

2097152 Bytes - 2031616 Bytes = 65536 Bytes
= 64 KiBytes

"dd" also starts counting from 0

0x200000 - 0x1F0000 = 0x10000
0x1FFFFF - 0x1EFFFF = 0x10000
0x1FFFFF - 0x1F0000 +1 = 0x10000

3rd hexrange in decimal
0x10000 (hex) -> dec =(65536 Bytes)

File Sizes of all firmware files edited- and unedited = 2 MebiBytes (decimal):
2 MebiBytes (decimal) = 2*1024*1024 Bytes (decimal) = 2,097,152 Bytes (decimal)

2097152 Bytes (decimal) ->hexa-decimal
2097152 Bytes (decimal) =0x200000 (hex-dec.)

Offset including 0x0 <-> including Offset 0x1FFFFF
= 0x200000 Bytes (hex-dec.)


Code:
2097152 Bytes (dec) ->hexa-decimal

2097152 Bytes (dec.) = 2*1024*1024 Bytes

1024 decimal ->hexa-decimal:
1024 / (16^3) = 1024 /4096 = 0
1024 / (16^2) = 1024 / 256 = 4 Rest 0
0000 / (16^1) = 0000 / 16  = 0 Rest 0
0000 / (16^0) = 0000 / 1    = 0 Rest 0

1024 decimal ->hexa-decimal
= 0x400 (hex)

0x400 (hex-dec) * 0x400 (hex-dec) = ?

=>4 (dec.) -> 0x4 (hex-dec.)
=>4 (dec.) * 4 (dec.) = 16 (dec.)
16 (dec.) = 0x10 (hex)
=>0x4 (hex-dec.) *0x4 (hex-dec.) =0x10 (hex-dec.)

=>0x400 * 0x400= (0x4 *0x4 * 0x100 *0x100)
=0x10 *0x10000
=0x100000

0x100000 *0x2 =0x200000

2097152 Bytes (decimal) ->hexa-decimal
2097152 Bytes (decimal) -> 0x200000 Bytes (hex-dec.)

Offset including 0x0 <-> including Offset 0x1FFFFF
= 0x200000 Bytes (hex-dec.)

0x200000 =(0x200001-th) Byte (starting with Byte number 0x0)

0x1FFFFF =200000-th Byte

---
  0x200000
- 0x1F0000

     1
----------------
   0x010000

  (0x0 <-> 0x1FFFFF) =0x200000
- (0x0 <-> 0x1EFFFF) =0x1F0000
=0x010000

  0x1FFFFF
- 0x1F0000
-------------
  0x00FFFF

(including 0x1F0000)
0xFFFF + 0x1 =0x10000

0x10000 (hexa-decimal =>dec.

0x10000 (hex) ->(dec.)
=1 *16^4 + 0 *16^3 + 0 *16^2 + 0 *16^1 + 0* 16^0
= 16*16*16*16 + 0 +0 +0 +0
=256*256
=65536 Bytes
=65536 Bytes / (1024 Bytes/KiByte)
=64 KiBytes
 
Last edited:
Hi guys,


What I need

Please send me a valid dump of BU40N/BU50N/BP60NB10 devices if you have one of them. It will be needed for further testing purposes.
Thanks !!!

How does one dump the firmware from the BP60NB10 and the WH50NB40? They've got USB connectors and there are no SATA ports inside to connect to.
BU40N/BU50N no problem I've got those if you still need dumps
 
Teddy no longer does the modifying, and the bu40n/bu50n won't work with anydvd. They're official uhd drives and anydvd only works with friendly ones.

Verstuurd vanaf mijn Nexus 6P met Tapatalk
 
So, does this work? I'd quite like if an ASUS BW-16D1HT could work with Cyberlink PowerDVD 17 for UHD discs.
 
You want to convert an ASUS Bw16d1ht (a drive that does work with anydvd) into an lg wh16ns60, (a drive that does not work with anydvd) for the purposes of watching UHD Blu Rays from the drive itself?

That sounds like a huge waste of time when you can simply rip the disc to a file playable from a myriad of of both hardware and software products.
 
Status
Not open for further replies.
Back
Top