Dumping & Downgrading firmware on UHD Friendly Devices. (OUTDATED)

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

  1. theosch

    theosch Well-Known Member

    Yes sure, whatelse do you expect? :)

    Sry, . OK maybe I misread, as often happening, but as far I understood you, crossflashing the BH60NS60 to Asus firmware helped solve BD-RE/BD-R burning issues.
    [Edit]by reflashing with Asus firmware-crossflah from other Asus unit, with the encryption data from (from problematic unit's previous-firmware?) moved to.

    Maybe before the reflash, where an Asus firmware was already crossflahed onto BH16NS60 ,one of the methods, Teddies hexedit method or EEPROM data mover, or wrong hexediting caused problems, or s.th. else wrong.
    Afaik MartyMc Nuts method with the specially modified Clean firmwares, afaik it does also the data moving, it also contains BH16NS60 1.00 specially modified Clean-firmwares. So Afaik it is also for converting official-UHD-drives to UHD friendly. What method does it use a official-UHD-->UHD-friendly conversion (e.g. if using to crossflash BH16NS60 to BW-16D1HT 3.02/3.01/3.00 firmware?

    Maybe if it uses one of those method here, too, Teddies hexrange or EEPROM data mover built-in, or else, not to touch? maybe if one of that method (or wrong hex range in a such occasion, not to touch,built-in in causes burning issues (see phenomenon, see below)

    Sry I forgot, I'm wrong, the new method does not move or touch the laser calibration data.

    Still the new flashing method it mustn't touch a wider hexrange with official-UHD drives to UHD-friendly for crossflashing/conversion (within same manafacturer line or to ASUS).
    Afaik still the original not newly official LG flasher (patched) is used, maybe it uses smaller hexrange from normal UHD-fiendly firmwares which might cause problems for official-UHD-conversion, because the first hexrange is 0x1E0000 to 0x1E84FF, and not 0x1E8000 to 0x1E84FF (smaller hexrange). Maybe the patched LG flasher doesn't watch this.

    I'm only speculating.:)

    [Edit] By the way:


    The EEPROM data mover certainly seems to output different result (different file checksums) than using with Teddies hexrange method upper link(!) (on a UHD-official->to UHD-friendly-conversion!) Just to clarify!

    And I know how to do the hexediting.
    (But I cannot program apps, programs, etc at all) :)

    Just test with both methods, should get same result, then run a file compare check between both resulting files, you should see that phenomenon.

    But the difference was outside of the DV value hexrange as far I remember, as I had exported the CB-DV encryption data to seperate files from both methods afterwards, and checksum from both exports least identical (from both files from both methods, but not from the main firmware data (so outside of the hexrange).
    (The EEPROM data mover- and hexediting method had been tested, because MartyMcNuts new probably safer method hadn't existed yet)

    That different behavior between both methods was not to see at all, with standardly-pricipially-already-UHD-friendly-drives firmwares that would need other guide instead
    (or now MartyMcNuts new safer method for most probably all those cases)

    You said you had had no issues with your BH16NS60 drive Converted/crossflashed from the first place.
    In which way did you crossflash your NS60 drive? Please kindly could you give a link or description from where instructed doing it, or explain how done it? :)

    E.g. did you use this guide?

    Or EEPROM data mover method, or MartyMcNuts method, or other way?

    Please could you tell which one of those.
    Or if other, then how? Thx :)
    Last edited: Mar 11, 2019
  2. SamuriHL

    SamuriHL Moderator

    He used the safe method to cross flash... The same method I was testing. To be very clear here, I was only testing things because testiles was having issues with his ns60 cross flashed to Asus 3.02 using the safe windows flasher. He fried about 4 bd-r's after flashing it so he asked me if I could test with mine to see what results I got. Normally I keep mine on ns60 1.00. Anyway when I flashed mine using the windows flasher and tried to burn a verbatim bd-re 25 it fried the disc to the point I couldn't recover it. Flashing back to ns60 1.00 allowed me to burn the same image to the next disc in the spindle.

    Now my curiosity got the better of me because I had used the dosflash method originally to downgrade the ns60 so I still have a USB stick to flash that method. I took my original extracted firmware that came with the drive, and manually moved the encryption data to an Asus 3.02 firmware that I extracted from my Asus drive. The end result is a firmware that matched my Asus drive except for the encryption data. Using dosflash I flashed that to the ns60 and tested another burn. No issues at all.

    I feel like using the calibration data from the ns60 with the Asus firmware is what caused the burn to fail. Once I used the Asus calibration data the burn was successful. Testiles ultimately used s different LG firmware to make the drive uhd friendly for anydvd and has been able to burn fine with that.

    Short version... Cross flashing using the patched windows flasher caused burn failures for two of us. Dosflashing the Asus calibration data while cross flashing worked for me. Cross flashing to another LG firmware worked for testiles using the patched windows flasher.

    Hopefully that clears it up.

    Sent from my Pixel XL using Tapatalk
  3. BRCS

    BRCS Well-Known Member

    I used the Asus downgrade tool with the modified asus flasher using asus firmware 3.01 on my NS60 JFYI.
    theosch likes this.
  4. theosch

    theosch Well-Known Member

    Ok so with the safe method, so with the Windows LG flashing utility converting B/WH16NS60 UHD-official to UHD-friendly Asus BW-16D1HT didn't work so well with burning, as far I've understood.

    So there is no issue with burning with original BH16NS60 1.00 firmware so far.

    So you didn't take an Asus BW-16D1HT Clean firmware, rather (a copy) of your original Asus 3.02 dump to move the data into?
    So you moved NS60 dump encryption data into BW-16D1HT dump, with the encyption data from you NS60 when using the manual method afterwards?

    It didn't work well with burning?
    Interesting. No offence, because you surely you know how to do hexediting correctly.

    [Edit] wrong sry I misread/misunderstood.
    Expected, "encryption data doesn't match" =>wouldn't mean work with UHDs"
    The encrption data from other unit's dump (Bw-16D1HT) of course can't match to BW-16D1HT, as imported into a dump of other unit.

    But burning goes fine, when using Dosflash, and probably older converting/downgrade-methods were used here.

    In which way did you manually move the encryption data from your original NS60 1.00 firmware to the Asus 3.02 firmware?
    (So after the LG utitily method was tested out with not 100% good results)
    Did you use EEPROM data mover to do it manually or with hexediting (e.g. with hexeditor or with "dd", etc) ? But this didn't work well with burning either?

    In case you used manual hexediting hexeditor method but not (EEPROM data mover), you used first other hexrange 0x1E0000 to 1E84FF ?

    So the patched flasher (perhaps) might have issues when crossflashing UHD-official firmware to UHD friendly, at least with burning, or just in some occasions.
    But using opposite, Asus 3.02 laser CB+encryption data into NS60 dump worked?
    when it's a crossflashing within UHD-friendly fws.

    But maybe not when it's only a UHD-officical downgrade.

    Maybe the patched flasher it does only not touch 0x1E8000 to 0x1E84FF), but it maybe it touches 0xE1000 to 0x1E7FFF, which it shouldn't, which is taken along UHD firmwares conversion, as Teddy's 2nd guide is showing)
    Maybe the original LG flashing utitily originally might not be programmed to look for that wider range, not to touch those additional 0x8000 bytes (that are in front of) 0x1E8000 in the first hexrange, so overwrites them with corresponding data offests' data from the output firmware file.

    2ndly maybe if using Asus update utility on a B/WH16NS60 unit converted to BW-16D1HT maybe it's necessary to also import that wider hexrange, but the Asus Update utility just uses 0x1E8000 to 0x1E84FF, but not 0x1E0000 to 0x1E84FF (so 0x8000 bytes missing)
    Maybe this causes issues with originally B/WH16NS60 units crossflashed to Asus BW-16D1HT 3.01/3.00, then when using Asus Update utitlity to BW-16D1HT 3.02

    I'm confused about what I'm telling. Maybe it doesn't make any sense.
    A fews thought circling around.

    Step 1a)
    Maybe I'll need to crossflash a BH16NS60 original firmware (UHD-Friendly to UHD-official) onto my BH16NS55, from another unit.
    Or maybe I'll better use B/WH16NS60 1.00 Clean firmware for that testing.
    I'll use manual hexediting method with Teddy's first 0x1E0000 to 0x1E84FF hexranges, (other two hexraanges are the same).
    Step 1b) I'll use Dosflash to flash that file over.
    (Also original firmware dump backed up)

    Then I'll attempt crossflash back to UHD friendly, but for the BH16NS55 now using Asus BW16D1HT firmware now using the Windows LG utitily. And dump this with Dosflash.

    Then I'll attempt a 2nd downgrade from BH16NS60 firmware created from my BH16NS55 original dump (see step 1), (downgrade in firmware file extra test without needed to flash over), to Asus BW16-D1HT Clean firmware.
    Again I'll use manual hexediting method with Teddy's first 0x1E0000 to 0x1E84FF hexrange, (other two hexrange's offsets are the same), but vice versa 2nd time, now not with LG utitily.

    Let's see if the resulting files from LG flasher UHD-offcial-UHD-friendly crossflash back and manually hexiditing to Asus BW-16D1HT will be the same. If not the culprit then might be the LG flashing utility, given if I did hexediting corrrectly.
    Just to say it's not that difficult, but I take about an hour time for hexediting doing it, so to hopefully make no mistakes. Few times had to correct me, did an error,
    doing it again but then rechecking showed, did finally it correctly.
    But I'm really rather slow :)

    The issue is with those modified Clean firmwares acceptable for the patched LG utility. I'm not sure if I should take "DE_LG WH16NS60_1.00.bin" specially modified for manual hexediting method, as one byte different, as MartyMCNuts or SamuriHL told. I'd propose the LG utility compensates for this to adapt that this 1-byte-change isn't really flashed over.

    I'd prefer those Clean_NS50_compatible_firmwares.7z, and other WH16NS60 Clean firmware I got elsewhere not included in the archive,without that byte-change for those manual hexediting/hexeditor or with "dd" -experiments.
    Last edited: Mar 11, 2019
  5. SamuriHL

    SamuriHL Moderator

    Just want to clarify cause you still seem confused. The encryption data hex edited into my ASUS 3.02 dump from my BW-16D1HT and flashed through dosflash worked perfectly for EVERYTHING. Burning, ripping, etc. That was the point of trying it. I had a feeling it would work quite well with the proper calibration data and I was correct. It essentially turns the NS60 into a BW-16D1HT. You have to remember, these drives all have the same basic hardware under the covers. The NS60 has additional hardware to handle official AACS2.x decryption, but, the basic chipset is all the same. Hence why I figured it was a calibration data issue, and it was. Flashing with the official flasher doesn't modify the calibration data which is why I had burning issues when cross flashing with that method. For me the whole thing was an academic exercise as I have a real ASUS drive and the NS60 in the same machine.
  6. SamuriHL

    SamuriHL Moderator

    P.S. You seem to be making this MUCH more confusing with all the supposition than is necessary. The LG firmware and the ASUS firmware use different calibration data. I can't account for BRCS' success with cross flashing (maybe the ASUS flasher does something different but I seriously doubt it)....could just come down to the brand of disc being written to. I use Verbatim for all my optical media. From Japan. In any case, it comes down to the calibration data being different which is why I didn't use a "clean" ASUS firmware or use the data mover tool as that would have been pointless and just ended up with the LG calibration data. Hence why I manually hex edited my encryption data into an extracted firmware with known good calibration data for an ASUS firmware. Like I said, you seem to be confusing yourself with all of the guessing and it's really pretty simple...if you want to cross flash AND burn, you MAY have to use the calibration data from the firmware you're flashing TO *IF* your burns fail when using the patched Windows flasher (or patched ASUS flasher). That's it.
  7. theosch

    theosch Well-Known Member

    Thanks for helping. Yes it's confusing. But modifying the calibration data of a drive being crossflashed to other model, is generally not intended, correct?
    As it should just be moved over completely?
    So you mean the LG flashing utility didn't modify the calibration/encryption data on the output file (your BW-16D1HT original dump),when output file is a dump, not a clean firmware, combined with a UHD-offcial firmware as input file?
    (So the LG utitily didn't transfer over the NS60 encryption data /or not completely to your BW-16D1HT original dump-copy, causing the burning issues?)

    So better using the CB data from the output file (the firmware flashing TO)
    But otherwise using the calibration data of the output file worked fine for burning.

    The confusing stuff is, that it was said that the original laser calibration data (or maybe rather the dv value) was needed for handling bus encryption on UHD discs.
    So with it lost it wouldn't work.

    Then listed s.th. about AnyDVD, that it would ignore wrong drv signature from new versions up.

    I said in a past, so now with dv value lost, so with a cloned firmware UHD now still might work with AnyDVD. But also I heard s.th. from other person, the new AnyDVD versions wouldn't fix that. Confusing :)

    What I always asked me, why using Clean firmwares? Just expected, mainly having the CB/encryption data of original unit for crossflashing/downgrade/convert to copy over into a firmware dump. That should just do it.
    So with the old method (EEPROM data mover), the Clean (incomplete) firmwares (dumped by devils flasher) , were just needed for EEPROM data mover to accept doing the hexediting.
    Last edited: Mar 11, 2019
  8. SamuriHL

    SamuriHL Moderator

    Ok, you are still VERY confused on this. So I'm going to be EXTREMELY clear on this.

    When using a patched windows LG flasher OR the patched windows ASUS flasher, *ONLY* the firmware data is being flashed. This is why a clean firmware is preferable because it is *NOT* flashing the encryption data block OR the calibration data block with these tools. That is why when you cross flash from, let's say an NS60 to a BW-16D1HT, the calibration data from the drive's original LG firmware is still present and appears to cause some of us burning issues on some firmware. Again, those tools WILL NOT flash the encryption data OR the calibration data.

    The old method is using dosflash. This method is said to be dangerous BECAUSE it flashes the ENTIRE firmware, including encryption data block and calibration data block. In fact, it actually ERASES the entire EEPROM on the drive before it lays down the firmware data blocks (I think there's 32 of them if I'm not mistaken) start to finish. If you flash a firmware that doesn't contain your encryption data it will brick the drive. That's why it's dangerous. There's no safety checks like the windows patcher tools. If you f*** up the editing of a firmware bin and flash the drive, you may brick it. It is *ALWAYS* recommended that you use the read function in dosflash BEFORE DOING ANYTHING to extract the firmware from your drive. As long as you have that, you can almost always recover the drive.

    But the dosflash method is also one that I exploited because I wanted the calibration data from my ASUS drive (which has never been flashed with anything other than official non patched ASUS flasher to get it to 3.02) but the encryption data from my LG drive. So I took my dosflash extracted ASUS firmware and manually hex edited the LG's encryption data into it and flashed it with dosflash. This essentially turned the NS60 into a full blown BW-16D1HT friendly drive and had the ability to write to the media that was previously failing when it had the ASUS firmware with LG calibration data. Which is kuel and useful for some people. I was simply doing it to figure out what the issue was for testiles. He ended up flashing an NS50 firmware I believe which "kept the calibration data in the family" so to speak. Meaning cross flashing an LG to LG without overwriting the encryption data or calibration data by using the patched windows LG flasher. That worked for him. Personally I keep my NS60 on the 1.00 firmware as I dedicate that drive to another ripping software. My BW-16D1HT is dedicated to AnyDVD/CloneBD. I also don't write any media so for me this whole thing was purely academic.

    To sum it up....the patched Windows ASUS and LG flashers DO NOT write the encryption or calibration parts of the firmware. Therefore it is safer to flash with this method. Dosflash, however, erases then overwrites ALL parts of the firmware and thus needs the encryption data and calibration data to be moved to the target firmware you're flashing else you will brick the drive. Dosflash is MUCH more volatile and potentially destructive.

    Hope this helps clear this up a bit more.
  9. theosch

    theosch Well-Known Member

    Yup really important to watch that, especially using Dosflash and LG utility as it also allows flashing (principially) any dumps (only not in one situation case)
    Just the EEPROM data mover rejected modifying into firmware dumps, it just allowing into Clean-firmwares.

    OK when crossflashing, eg. from UHD offciail to other product line, it might happen that resulting laser-calibration-data (hexranges?) <->the main firmware (outside of those hexranges) doesn't fit together, even if doing correct hexediting, or even when using those new tools, itself actually doing all correctly.

    For that cases you have to locate encryption data and CB-data and seperate them from each other. So exporting the encryption data from NS60 unit into BW-16D1HT firmware, but not the CB-data included, so using the CB data from Asus BW-1&D1HT unit?

    If so,
    this method, how to do that, is not mentioned by Teddy?


    The encryption block isn't it within those hexranges? always thought so. But maybe I'm wrong.

    Yes I know. But good to always mention, with new posts, people stay alarmed :)

    The encryption data and calibration data, are they both in the hexranges you tranfer over, or seperated? One inside the other outside??

    I heard people crossflashing BH16NS55 to BW-16D1HT 3.02. And Teddy mentions and recommends in his guide to transfer over those three hexranges from original LG unit.
    But when tranfering over that three hex ranges, then the CB data of the LG unit is still used? Isn't it?
    Why should BH16NS55 crossflahed to BW-16D1HT run faster, when those data is still from LG unit?
    I presumed Laser CB data had s.th. to do with laser adjusments and improvements for reading discs. So if other laser calibration data, perhaps other disc-speed-reed-out behavior.
    I probably misunderstood, and that CB data is outside of those hexranges, then...

    LOL I always expected I knewa (a bit), but now I feel I misintepreted everything, got wrong conclusions.

    Yes I know already. The last questions were more theory, if you watch to transfer over those hexranges correctly (from original unit's dump) for that original unit, e.g. with the new LG patched utitly into a dump of other unit if it would make any difference whether into a Clean-firmware or firmware-dump (into a Clean-firmware what would be highly recommended)

    (Just theoretical question)
    I presume in theory no it doesn't, but much more risky, if doing s.th. wrong.
    Last edited: Mar 11, 2019
  10. SamuriHL

    SamuriHL Moderator

    With the patched LG or ASUS flashers, it doesn't REALLY matter if it's clean or not because it's not going to flash the data blocks for the encryption data or calibration data. The calibration data isn't what makes the drive faster or slower, btw. That's controlled by the firmware itself and ASUS' is slightly faster....although the NS60's native firmware is about 1% faster than the ASUS.

    As for the data blocks and their locations when hex editing, this is directly from Teddy:

    I would argue that's not entirely true on his last point there, but, I suspect he didn't do a lot of burning of different media. The data mover tool does this for you for both encryption block and calibration block. And this only matters when using dosflash to wipe the whole firmware and rewrite it. The patched windows flashers will just skip those blocks.

    In the case of the hybrid firmware I made from my extracted ASUS firmware, I simply copied the encryption data block at 0x1e8000 and pasted it into my output bin file. That then used the calibration data block of the extracted ASUS firmware with the encryption data block from my LG drive, thus creating a fully functioning ASUS drive. But I had no real need to keep it like that. And quite frankly, I don't like messing with dosflash all that much as one screw up could brick the drive. This is why the information for downgrade enabling firmware was made publicly available so people would stop messing with dosflash. And if you own an LG drive, IMO flash an LG firmware to it rather than trying to cross flash it into an ASUS. Otherwise just buy an ASUS drive. That's just my opinion and if a person isn't going to be writing the media types that failed for testiles and myself, then crossflashing just to turn it into a friendly drive for reading UHD's will work just fine. And BRCS has his working crossflashed and writing his media so who knows. What I do know is I'm leaving my NS60 alone on 1.00 and will continue to use it for what it's dedicated for. AnyDVD doesn't like that drive so it's disabled for it. But it loves my ASUS drive.
    theosch likes this.
  11. theosch

    theosch Well-Known Member

    OK I potentially just interpreted too much magic into it. The new crossflashed firmware by Asus simply doesn't like some media brands, whereas the previous LG firmware did. So with BRCS having it working on crossflahed BW-16D1HT, maybe he simply had other kind of BD-RE/BD-R brands which don't make trouble on the Asus firmware, but if he had exactly the same brands of BD-R/RE as testiles or you or other way round, it probably would also cause burning issues on those ;)

    The problem is I try to read, forget s.th. and remember s.th., but have difficulties to remember text (short-term memory buffer in such thing).
    Last edited: Mar 11, 2019
  12. SamuriHL

    SamuriHL Moderator

    That's the working theory. Otherwise, his using the ASUS flasher to cross flash potentially did something different than the LG flasher did but I find that theory highly suspect. I do know that flashing the ASUS 3.02 firmware using the LG patched flasher from LG NS60 1.00 caused my Verbatim BD-RE 25 writes to fail. And after I dosflashed the calibration data, they wrote perfectly fine. So who knows. I'm only working on theories at the moment.
    theosch likes this.
  13. theosch

    theosch Well-Known Member

    OK you did some special modifying, staying the Asus BW-16D1HT's CB-data, only exporting the original encryption data from your BW16NS60 into BW-16D1HT (dosflashing method), so not mentioned by Teddy, taking over CB-data from Bw-16D1HT, but not taking over the CB data from your LG BH16NS60 drive.

    And the LG patched flasher doesn't create those hybrids (assumption), so it's staying the LG CB-data along with the encryption data (so LG-data CB-data not seperated off from encryption data) so staying LG CB data, which is not always as good in burning as the CB-data from Asus.

    Well if so, yes it sounds plausible to me, why it accepted those brands with the Dosflashed firmware method, because you left the CB-data from Asus unit taken over, but why not with the utility.
    The CB-data maybe doesn't do so much with drive's read speed (main firmware outside does), but it has effekt on laser calibration, and laser calibration is done by unit before burning a blanc disc. How to control that is in the CB-data.
    The drive tests for right laser-strength before starting recording in a specified reserved area for that for optimal burning results.
    Or use the some kind of CB-help data stored on a blanc.
    Maybe some brands lack of that kind CB-help data. At least heard from s.th. like this.
    And if it's missing on a cheaper brand, the firmware having a better necessary laser adjustments technique then is more important.

    MRCS had "luck" that his LG-CB-data taken with, by him using LG utility, the LG-CB data plays together with his BD-R/RE media brands :)

    I also heard that sometimes the LG firmware plays togethether better with other discs.

    I have an 2 BH16NS55 and 2 BW-16D1HT. I'll leave those four as they are, to be able to combinate both adavtages from them in case of readout-trouble.
    Again I'm only speculating and probably telling nonsense. :)
    Last edited: Mar 11, 2019
  14. SamuriHL

    SamuriHL Moderator

    He didn't use the LG patched flasher, he used the ASUS patched flasher. Not that it should matter as both the LG and ASUS flashers are flashing only parts of the EEPROM which does not include the calibration data or the encryption data. But, there could be another difference there that I'm unaware of. I don't particularly want to fry another disc so I'm not about to try the ASUS patched flasher to see if it makes any difference, but, that's the one thing I did not try using. So who knows on that one.
    BRCS and theosch like this.
  15. HansQualm

    HansQualm New Member

    I got the same error message. Update progress bar goes to 100%, after a few seconds that message appears and when I click on "OK", the flasher window will be closed. My hdd led lights up permanently and after a while the PC hangs up or shuts down.
    The firmware itself seems to be flashed correctly and my BD drive still works without issues.
  16. Dick D

    Dick D New Member

    Hello TeddyRaspin

    I have attached my stock firmware for my ASUS BW-16D1HT .

    I would appreciate it if you could fix me up with your modified version.

    Thanks in advance

    Dick D

    Attached Files:

  17. SamuriHL

    SamuriHL Moderator

  18. Dick D

    Dick D New Member

    Thanks for the information SamuriHL , I appreciate the response
    whatever_gong82 and SamuriHL like this.
  19. SamuriHL

    SamuriHL Moderator

    I did some more testing today to see if I could get the NS60 cross flashed to ASUS 3.10 MK and retain burning capability while using Marty's ASUS flasher. Unfortunately, I was not successful. I didn't fry my discs this time as I simply chose to try to erase a BD-RE 25 and it failed. Flashed back to NS60 1.01 MK and was able to erase it just fine. So for me, at least with Verbatim media, I am not able to use the Windows flashers to cross flash my NS60 to ASUS firmware and retain write capability. Bummer.
  20. joe711

    joe711 New Member

    Hi Teddy, I used the dosflash method on a bw-16d1ht and got through dumping firmware and hex editing. When it went to wright the updated firmware to the drive dosflash could not find the firmware file i loaded on my USB.
    Any suggestions?