Dumping & Downgrading firmware on UHD Friendly Devices.

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

  1. Nicko

    Nicko Member

    Don't think that Dosflash can handle USB Drives.
  2. Andreas Daum

    Andreas Daum Member

    I thought it works
  3. TeddyRaspin

    TeddyRaspin Well-Known Member

    Newer firmwares don't allow to be dumped via devilclaw's flasher.

    Furthermore, for external/slim UHD drives, DOSFlash is not working due to its limitations to IDE SATA ports only. :(
  4. ed_co

    ed_co New Member

    As I said, I am almost sure is something sure that there is something in the line: flasher -d 1 -l firmware.bin 6 00000000 00200000, which is not correct as the drive is correctly recognized.
    The thing is, I don't understand the meaning of 6 00000000 00200000, but it is most likely, that this is the problem.


    P.S.: I am on MacOS
    Last edited: Feb 10, 2018
  5. theosch

    theosch Well-Known Member

    Does this include official UHD drives (non-UHD-friendly), too?( which normally wouldn't allow any rip at all)?
    I've had postitive experience with Pioneer drives. Unfortunately they are not UHD friendly, not any method is/was known to get them UHD friendly.
    Can you make Pioneer drives UHD-friendly, too?

    I know there's "dvrtool" or "drvflash" for Pioneer drives to update and revert back firmware and crossflashing on Pioneer drives:
    DVRTool - Pioneer DVR/BDR firmware flashing utility (v1.02):
    Last edited: Feb 11, 2018
  6. TeddyRaspin

    TeddyRaspin Well-Known Member

    The -l (or --dumplock) command used for the devilclaw's flasher, dump a specific region in hex format, thus writing 00000000 00200000 creates a 2 Megabytes file size (as it should be).
    What I've never fully understood is the number '6' before that range which should indicate an hex value/string. I've changed it to 0 and it seems to dump but the resulting file is empty.
    So, maybe, in your case as well as in the case of latest firmware versions, that value should be more investigated but I've not found any info about that yet.

    As far as I know, and for my own experience, All Asus/LG UHD Friendly SATA Internal drive can be crossflashed to LG WH16NS60 1.xx firmware as Real UHD drives and viceversa,
    meaning that a WH16NS60 can be flashed to a BH16NS55 for example (which is a UHD Friendly drive).
    I was wrong about converting BU40N/50N or BP60NB10 (which are slim/laptop and external real UHD drives) into UHD friendly device, because firmwares are not compatible, even
    if they share same MediaTek chipset.

    Regarding Pioneer devices, DVRFlash is for DVR-xxx models (dvd burner), while DVRTool handles also BluRay units but it does not allow to crossflash between BDR-207-208-209-211 (or S07-S08-S09-S11)
    due to its limitations and security features of Pioneer firmwares.
    This is very sad, because I've seen S09 and S11 PCBs and they are pretty the same. With an external programmer it should be possible to dump a S11 or 211-UBK firmware and flash it on a BDR-209/S09 device
    making it capable of reading UHD discs without any issues at all, but Pioneer has chosen to force users to buy their expensive units (BDR-211) so I'm wondering how a BDR-209 has the BDXL stick on the front panel
    if it can't read any UHD disc at all. :(
    theosch likes this.
  7. liels

    liels Well-Known Member

    Thank you! You people are awesome.
  8. BonumMonstrum

    BonumMonstrum New Member


    I couldn't import data from my original file.
    My drive is BH16NS40 - I created a save from my firmware, then I tried to create a patched firmware with WinHex and also with EEPROM Data Mover. I used the clean firmwares that I've found in the german thread.

    I've tried:
    flash_HL-DT-ST_BD-RE_BH16NS40_1.02_NS50.bin with EEPROM
    flash_HL-DT-ST_BD-RE_WH16NS40_1.02_NS50.bin with EEPROM (that's my FINAL.BIN atm)
    flash_HL-DT-ST_BD-RE_BH16NS40_1.02_NS50.bin with Win Hex (that's my TEST.BIN atm)

    EDIT: Now I also tried flash_HL-DT-ST_BD-RE_BH16NS40_1.03_NS50.bin with EEPROM from this thread.

    Unfortunately, afterwards my drive didn't recognize any DVD/BD - only i can open the tray.
    Also, when I flashed these BIN files my drive didn't have any blue light. However, when I flashed my original file the blue light appeared after flashing. So I think I'm too stupid for patching my files! Can someone help me, maybe? :D

    Thanks in advance everyone!!

    Btw, here is the german thread from which I downloaded the clean firmwares:

    Attached Files:

    Last edited: Feb 12, 2018
  9. theosch

    theosch Well-Known Member

    Maybe you have BH16NS40: SVC-Code "NS40" or ROHS (produced 2014). If that should be so you have not a UHD compatible drive.
    If that should be so, you need a BH16NS40 SVC-Code NS50.

    Please check the label sticked on the upper side on your drive that there is SVC-Code NS50 (this is produced about minimum starting from 2015 afaik).
  10. TeddyRaspin

    TeddyRaspin Well-Known Member


    Here is your recovery firmware, which should make your drive able to read CD/DVD/BD discs again without any issues at all.

    You have first to erase eeprom and then flash it, using the attached file below, via DOSFLASH modified version (and FreeDos or pure DOS system).

    Attached Files:

  11. theosch

    theosch Well-Known Member

    It might be (perhaps) that the EEPROM Data Mover is not always doing the proper thing in all cases (only an assumption). On one firmware dump import checksum from EEPROM Data Mover matches to the other method via "dd".
    On the other firmware, it doesn't.

    See more further below especially screenshots and the Code:

    I have two BH16NS55.
    The 1st BH16NS55 (Retail) came with FW 1.02
    The 2nd BH16NS55 (Bulk) came preinstalled with FW 1.03.

    At first I made a dump of both drives (Bulk and Retail) each with Dosflashed 1.7 you provided.
    1st BH16NS55 (Retail): LG_BH16NS55_SN_70XXXXXXXXXX_Orginal_FW_1.02_dumped_Dosflash_1.7.bin
    2nd BH16NS55 (Bulk): LG_BH16NS55_SN_71XXXXXXXXXX_Orginal_FW_1.03_dumped_Dosflash_1.7.bin

    Then I imported the data from the dump to to the correspondending SAME firmware version of the clean firmware.
    I had some strange beavior that the EEPROM data mover is not always doing the same thing in all cases compared using "dd".
    The idea was a try to find out if the EEPROM data mover and/or "dd" hexediting can reproduce original firmware dump from clean firmware and importing parts from the Original dump.
    ,by using same corresponding firmware version of clean firmware to the same matching SAME fw-number of the Original dumps.

    I made the importing data-hex-editing through "dd" (find it easier) on clean firmware
    I also used the EEPROM data mover for second attempt on a clean firmware

    It might be (perhaps) that the EEPROM Data Mover is not always doing the same thing in all cases.

    See screenshots:
    But I'm pretty sure I made all correct, and "dd" starts counting up from 0 like the hex-editor.
    0x1E8000 = 1998848 dez
    0x1E84FF = 2000127 dez
    0x1E9000 => 2002944dez

    => 0x1E84FF - 0x1E8000 = 0x4FF (Delta) =1279dez
    => 2000127dez - 1998848dez=1279dez
    =>Because including/counting in 0x1E8000 =>1279+1 =>1280 Bytes
    So the first import range from 0x1E8000 (including) to 0x1E84FF (including) that should be 1280 Bytes:

    LG_BH16NS55_SN_71XXXXXXXXXX_Orginal_FW_1.02 (Retail):
    For testing purposes I have used 1.02 BH16NS55 clean firmware, and importing 1.02 firmware dosflash dump into BH16NS55 1.02 clean firmware
    cp -a  ../forum.cdrinfo.pl_dosflash-v2-0-patched-support-bh16ns40-bh16ns55-drives-96930/Clean_NS50_compatible_firmwares/flash_HL-DT-ST_BD-RE_BH16NS55_1.02.bin  ./dd_hexediting_clean-firmware_-flash_HL-DT-ST_BD-RE_BH16NS55_1.02.bin
    dd  if=LG_BH16NS55_SN_70XXXXXXXXXX_Orginal_FW_1.02_dumped_Dosflash_1.7.bin  bs=1  skip=1998848  count=1280  of=dd_hexediting_clean-firmware_-flash_HL-DT-ST_BD-RE_BH16NS55_1.02.bin  seek=1998848  conv=notrunc
    dd  if=LG_BH16NS55_SN_70XXXXXXXXXX_Orginal_FW_1.02_dumped_Dosflash_1.7.bin   bs=1   skip=2002944   of=dd_hexediting_flash_HL-DT-ST_BD-RE_BH16NS55_1.02.bin   seek=2002944   conv=notrunc
    sha256sum  dd_hexediting_clean-firmware_-flash_HL-DT-ST_BD-RE_BH16NS55_1.02.bin   Data_Mover_1.02_Original-dump-Dsflsh_1.7_to_Clean-Firmware_BH16NS55_1.02.bin   LG_BH16NS55_SN_70XXXXXXXXXX_Orginal_FW_1.02_dumped_Dosflash_1.7.bin
    3e54efd7c8138366a1cc583d86fc524cd94675f651f7eebf24ced752c1e2ce40  dd_hexediting_clean-firmware_-flash_HL-DT-ST_BD-RE_BH16NS55_1.02.bin
    4a94bc1e3f87daf217af849d214e901927481f131daa212b168f4e26817083d4  Data_Mover_1.02_Original-dump-Dsflsh_1.7_to_Clean-Firmware_BH16NS55_1.02.bin
    9cfac42ebaac32cb0e575a014d9d21c7e3a1d560a430598e30b56628531949ce  LG_BH16NS55_SN_70XXXXXXXXXX_Orginal_FW_1.02_dumped_Dosflash_1.7.bin
    Result: different checksums all to each other (from "dd" and Data Mover different, and also different to Original Dosflash dump) :(

    LG_BH16NS55_SN_71XXXXXXXXXX_Orginal_FW_1.03 (Bulk):
    (For testing purposes I have used 1.03 BH16NS55 clean firmware, and importing 1.03 firmware Dosflash dump into BH16NS55 1.03 clean firmware
    Result: Same checksums all to each other ("dd" and Data Mover , and even to the Original Dosflash dump) :)
    cp -a  ../forum.cdrinfo.pl_dosflash-v2-0-patched-support-bh16ns40-bh16ns55-drives-96930/Clean_NS50_compatible_firmwares/flash_HL-DT-ST_BD-RE_BH16NS55_1.03.bin  ./dd_hexediting_clean-firmware_-flash_HL-DT-ST_BD-RE_BH16NS55_1.03.bin
    dd  if=LG_BH16NS55_SN_71XXXXXXXXXX_Orginal_FW_1.03_dumped_Dosflash_1.7.bin  bs=1  skip=1998848  count=1280  of=dd_hexediting_clean-firmware_-flash_HL-DT-ST_BD-RE_BH16NS55_1.03.bin  seek=1998848  conv=notrunc
    dd  if=LG_BH16NS55_SN_71XXXXXXXXXX_Orginal_FW_1.03_dumped_Dosflash_1.7.bin  bs=1  skip=2002944  of=dd_hexediting_clean-firmware_-flash_HL-DT-ST_BD-RE_BH16NS55_1.03.bin  seek=2002944  conv=notrunc
    sha256sum   dd_hexediting_clean-firmware_-flash_HL-DT-ST_BD-RE_BH16NS55_1.03.bin   Data_Mover_1.03_Original-dump-Dsflsh_1.7_to_Clean-Firmware_BH16NS55_1.03.bin   LG_BH16NS55_SN_71XXXXXXXXXX_Orginal_FW_1.03_dumped_Dosflash_1.7.bin
    82e60c0d0bd6010b13364a86097041b1b57a21dc8b152ff73ee1abd38e228f22  dd_hexediting_clean-firmware_-flash_HL-DT-ST_BD-RE_BH16NS55_1.03.bin
    82e60c0d0bd6010b13364a86097041b1b57a21dc8b152ff73ee1abd38e228f22  Data_Mover_1.03_Original-dump-Dsflsh_1.7_to_Clean-Firmware_BH16NS55_1.03.bin
    82e60c0d0bd6010b13364a86097041b1b57a21dc8b152ff73ee1abd38e228f22  LG_BH16NS55_SN_71XXXXXXXXXX_Orginal_FW_1.03_dumped_Dosflash_1.7.bin
    Result: All the same checksums , (from "dd" and Data Mover same, and even the same to Original Dosflash dump) :)
    2)_BH16NS55-(Bulk)_Data_Mover_checksum_same_to_dd-hexediting.PNG 3)_BH16NS55-(Bulk)_Data_Mover_checksum_same_to_dd-hexediting.PNG

    I can't explain it 100% why on one matches, on the other not. I used same "dd" parameters (except different clean firmware number using, but same model)
    Maybe I misenterpreted the hex-range range you provided slightly, so that the last number of the range maybe should not be included. I was not entirely sure, but using 0x1E8000 from start to including end of 0x1E84FF =4FF+1 =1280 Bytes appears rather plasible as instruction as 0x1E8000 from start to end of 0x1E84FE (=the end before right on the beginning of 0x1E84FF =1279 Bytes)

    So maybe on first firmware one byte too much on the first range didn't take any effect, because the Byte of clean firmware 1.03 in 1st range anyway has same value.

    Or maybe the clean firmware differs a bit (maybe from a Bulk drive). The checksum where it doesn't match was using Retail drive.

    @TeddyRapsin. Maybe you have an idea? :)
    I Hope all this pictures of exact documentation about what was done, do help and not confuse people.
    I was busy 30-40 hours in that unskilled testing through night and preparing all the documentation.
    Can't attach any dump in this post (too many pictures)
    This issue wonders and makes too busy, and I can't sleep so well without finding out the reason.

    I'll post the dumps in the next reply, in case you should be interested if you want to try to reproduce this issue.
    Last edited: Feb 15, 2018
  12. TeddyRaspin

    TeddyRaspin Well-Known Member

    Your post is of course useful, but I've never used the Eeprom Data Mover to create my recovery firmwares, nevertheless for the ones I've provided to users in order to downgrade their drives.

    So I don't know why there are such checksum differences. Furthermore I don't care if two different mods have or not the same checksum, because the only important thing is that the DV
    signature for the bus encryption is ok, the unit is working as it should for both BD and UHD discs.

    In your case, anyway, you seems to have a NS40 model, which is not UHD friendly, so the only thing you can do is to restore the normal behaviour of reading and ripping CD/DVD/BD discs. ;)
  13. BonumMonstrum

    BonumMonstrum New Member

    Yeah, it's true, I just looked at my drive and the code is NS40. I bought it in february 2015 so I have to buy the same drive again (or the NS55) in order to get a UHD friendly drive? :(

    Thanks for it, it worked like charm and now I have firmware 1.02 again. I'd like to know what I made wrong with creating my firmware, because I made everything like written in the turorial :/

    Nevertheless, it seems like I need to buy a new Drive so maybe I'll need your help next week again :D
    Last edited: Feb 13, 2018
  14. theosch

    theosch Well-Known Member

    Were the dd-paremeters used correct?

    I'm uncertain what way to use downgrading my LG BH16NS55 FW 1.03 (2nd drive) to 1.02:
    Either importing 1.03 Dosflash dump data (specific) hex range (from 2nd drive) into Clean firmware 1.02 and flash that on my 1.03 drive (2nd drive), or
    importing 1.03 Dosflash hex-range data (from 2nd drive) into a copy of 1.02 Dosflash dump (1st drive) and flash that on 1.03 (2nd drive).
    Which way to choose?? Both working?
    I'll use hexedit method via dd but there is still the issue below:
    There are quite a lot differences outside of the hexrange you provided between Original Dosflash dump of my 1.02 drive and the Clean 1.02 firmware.

    Well I can test it myself flashing both ways:
    1) Dosflash 1.03 dump's import's hex-range 0x1E8000-0x1E84FF + 0x1E9000-end into 1.02 clean firmware/
    2) Dosflash 1.03 dump's import's hex-range 0x1E8000-0x1E84FF + 0x1E9000-end into 1.02 Dosflash dump copy)
    Then try flashing both mtehods if works reading UHD discs.
    But I hope I can revert back, if UHD doesn't work or if drive should get out of order, at least I have the Original dumps.

    Example: Different areas outside of the hex-range between dd_hexediting_clean-firmware_-flash_HL-DT-ST_BD-RE_BH16NS55_1.02.bin

    And here's the difference between dd_hexediting_clean-firmware_-flash_HL-DT-ST_BD-RE_BH16NS55_1.02.bin

    {...}HL-DT-STBD-RE  BH16NS55 1.02N001901 UNIQUE1703101630MTEKMT1939   j!! {...}
    {...}HL-DT-STBD-RE  BH16NS55 1.02N001200 UNIQUE1512111440MTEKMT1939    " {...}
    Beyond compare message : "Ein Bereich unterschiedlich" = "One area different"
    Last edited: Feb 13, 2018
  15. TheCollective

    TheCollective New Member

    I've tried this on 2 computers now and after disabling CSM, I can only boot the USB drive in UEFI mode, which doesn't boot, just returns to the BIOS
    enabling CSM again allows non UEFI boot and it works and I can read the drive ROM with dosflash ok

    Is having CSM enabled going to mess up reading the drive's firmware? or is it ok to proceed with flashing the drive with the downgraded firmware?
    I'm kinda new to this so want to make sure I don't mess this up by not having a valid original fw dump to restore if things go terribly wrong :D

  16. PrimalNaCl

    PrimalNaCl Member

    Just as an aside, running those those files through xxd and diffing that output would make for easier viewing.
  17. TeddyRaspin

    TeddyRaspin Well-Known Member

    My mistake. You have to enable CSM, of course, and boot in Legacy Mode (not UEFI) from the USB stick. Then follow guide steps. ;)

    What are you meaning ? :unsure:
  18. TheCollective

    TheCollective New Member

    Thanks. I was sure it would be ok, but wanted to make sure. Now my new LG drive is working with UHD disks !!! :thankyou:
  19. PrimalNaCl

    PrimalNaCl Member

    I was responding to theosch. The diffs he was showing were of raw binaries. I was suggesting that running them through xxd and diffing that output, the diffs would be cleaner/easier to look at.
  20. Eleasar

    Eleasar Member

    Dear TeddyRaspin,

    thx a lot for your help, it finally works perfekt with the modified 1.02 you created with my dumped firmware 1.03 from BH16NS55. (y)