Converting UHD Friendly drive into UHD Real and viceversa

Discussion in 'CD/DVD/BD Drives' started by TeddyRaspin, Feb 9, 2018.

  1. Kwame Poku

    Kwame Poku New Member

    Does anyone know if Pioneer BDR-r09EBK is UHD friendly/UHD real Drive?
    If it is then is it possible to dump & flash the firmware as instructed by @TeddyRaspin.

    Thanks y'all.
  2. Steff123

    Steff123 Member

    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.

    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.
  3. Steff123

    Steff123 Member

    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
  4. Ch3vr0n

    Ch3vr0n Translator NL & Mod

    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
  5. Steff123

    Steff123 Member

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

    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.
  6. Ch3vr0n

    Ch3vr0n Translator NL & Mod

    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
  7. theosch

    theosch Well-Known Member

    Yes the WH16NS60 Clean firmware link ( 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

    After having original firmware-dump,+ stored safely:
    LG WH16NS60 fw.1.00 Clean

    Free Hexeditor for Windows "HxD"

    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

    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."
    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."
    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."
    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.)

    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 *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
    - 0x1F0000
      (0x0 <-> 0x1FFFFF) =0x200000
    - (0x0 <-> 0x1EFFFF) =0x1F0000
    - 0x1F0000
    (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
    =65536 Bytes
    =65536 Bytes / (1024 Bytes/KiByte)
    =64 KiBytes
    Last edited: Jan 30, 2019
  8. jonghotti

    jonghotti Active Member

    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
  9. Ch3vr0n

    Ch3vr0n Translator NL & Mod

    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
  10. txrx

    txrx Member

    So, does this work? I'd quite like if an ASUS BW-16D1HT could work with Cyberlink PowerDVD 17 for UHD discs.
  11. jonghotti

    jonghotti Active Member

    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.
    theosch likes this.
  12. SamuriHL

    SamuriHL Moderator

    It doesn't work anyway. Billy or Marty already tried it. PowerDVD fails to decrypt so there's more to the NS60 than just a firmware version.
    theosch, txrx and Marty S. McFly like this.