LiteOn iHBS112/212/312 Crossflashing & Firmware: Looking for a few tips?

vbimport

#102

No double sided, double layered, sorry.


#103

Just got this drive that was manufactured in 2013 but came with this old firmware on it. Dumped fine using dosflash without any special parameters.

https://mega.nz/#!bIAx1JIQ!yeJb9V-3DxApgwngGUvggupSdjDPtbR57t44-GRiVuo


#104

Sorry, just realized I had made a .7z and not a zip. Here’s the link to the zip file:

https://mega.nz/#!PEQXGKSI!dnqmmEVBdSBP4oPtK6JGdEjpkfJ-BCQXaf5MQcyKQCg


#105

The EEPROM code for the DH12B2SH is [B]BB[/B].


#106

Thanks. :slight_smile: I’ll check it out tomorrow & see about updating posts as required.


#107

[QUOTE=Albert;2756950]Thanks. :slight_smile: I’ll check it out tomorrow & see about updating posts as required.[/QUOTE]

Great! BTW, I tried flashing from the L firmware to the P fw on this drive using the unlocked flasher, but it failed both times. Is that expected behavior?


#108

Describe “failed”.


#109

So amongst other things, first let me say, this will be my recap of stuff i’ve missed, my motivation forward, and i guess, for lack of a better work, help/assistance i need (information, not money or compensation…come on guys :P)

my work on modifying drives and the software flashers (mainly extracting firmwares being where i ended up stopping due to IRL fam issues and personal problems, the financial expenditure on drives was minimal at that time…LiteOn clones as i have said before have been available from places for almost dirt cheap, especially OEM re-badges/clones as you al probably know. Now that BD is taking over, specifically writing, that price has increased, but has not become exorbitant (Anyone remember building a “Cheaper AMD rig” in like 2001 and for parts spending over 1200? Stuffs actually cheap now, perspective is everything.

Surprisingly software cracking/PE exploring, ASM/debuggers and memory spying in things like sandboxes take more time then just cross-flashing a drive with a utility released years ago, or coming up with a method (read: debugging repeated attempts to potentially brick drives :P) to circumvent checksums, encryption/“scrambling” etc… modification to low-level code is neccesary, and from what i’ve experienced, ASM most likely being the best candidate for this, plus “cracking checksums” ie removing what is legally “copy protection” i think…but thats a long past issue i think we’ve concluded on. We now own these drives. We can do what we want with them :slight_smile:

I’m sure these have been addressed already, or are far out of date answers, but for my catching up, I"m going to try and answer some posts with replies that are where i think i should be at with this, Its hard for me to cover all i’ve missed post wise, but addressing in this sticky with current developement people constantly updating/posting…seems perfect…and I’m curious on what’s left to be done and discovered.

SOOOO, Please, cvs, Albert, HM01, Paxster, blackened (blackened! my old buddy :stuck_out_tongue: PM me anytime!) and any who I overlooked as the sort of head guys/leaders/troubleshooters/contributers AND EVERYONE in this thread/attempt(s), please feel free to correct me and point me where i need to be to get back at this. blackened and I had initial discussions about my attempts to extract firmwares and things before I MIA’d, and he’s seemed to been essential in many ways during my absence (MUCH PROPS BRO)

Before he graciously picked up pretty much where i left off (blackened), and apparently branched out and learned/contributed tons (?), I didn’t have time to maintain my level of involvement (IRL can be a bitch), in working on my C D E crossflashing thread. After the thread was approved and even stickied (love you guys for that :stuck_out_tongue: it will live i imfamy) I was working the software side (I miss c0de :(), extracting the, at the time labelled “scrambled” firmware flashers.

I had (READ WILLINGLY AND EXCITEDLY, I LOVE THIS WORK) purchased well OVER 8 rebadge/clones offline and online, bricked 3, replaced 1 of the bricked ones, and then of course 3 official brand liteons new in box (obviously C D E rev…for the sticky), 3 asus rebadge, and the sony overburner drive (think its 5280S-CB…its in my sig, good drive, havent bothered modding it AT ALL though yet, had stuck to the LiteOn drives thus far, functionality exists for overburning to 8.5 on dual layers natively, and it wasnt neccesary for me to modify it for the uses i needed) and of course a authentic plextor 880sa, which allows plexutilities (had to see all aspects of LiteOn’s capabilities, even those that other OEM’s added or utilized (albeit differently and through native calls not available or possibly custom to plextors chipsets, however i havent crossflashed my liteon’s (nonplextor) to plextor and attempted, but i beleive i saw soemone else do so for use plexU. my only concern being that damaging a rebadge LiteOn or whatever may be easier when you can tweak it with PlexU, and burn out a laser, screw up ur burns, whatever…and perhaps even brick the drive. But as i have said, I have done little to no research on the PX series, its still stock fw (1.13) and i failed to be able to use ANY of the flashers to flash it…So i kept it stock…dumped fw and all that and sent it to cvs.

I tried to cover most of the bases of what was going on mod wise at the time, and what was missing…

I am no c0dek1ng though, and sadly, based on reading that we have no updated EEPROM reader, man i wish source codes were posted and stuff :P, but “we” have figured out EEPROM codes, i’m pleased to say that seems like major progress in that issue. Props to all involved again in that endeavor.
[B]
AT ALL COSTS PLEASE TRY AND KEEP AS MUCH OF YOUR OWN EEPROM AS YOU CAN WITH YOUR DRIVE, THAT MEANS LEARN HOW TO HEX EDIT, IT IS AS EASY AS USING NOTEPAD IF YOU KNOW WHAT HEX IS IN GENERAL. BACKUP BACKUP BACKUP. LABEL LABEL LABEL.[/B]

So here is what i see, as i said please feel free anyone involved to correct/advise/what have you anything you feel like. If you can cite sources, other threads, or progress made that has shown promise, that i my not be aware of, also include that. Feel free to PM me as well.

Here I go :stuck_out_tongue:

[QUOTE=cvs;2752886][B]WARNING:[/B] Please avoid flashing a drive with another drive’s EEPROM! :cop:

It might be a bit of a (necessary) pain, but people should really dump and then hexedit [B]their own EEPROM file[/B] not use someone else’s EEPROM!

Why? EEPROMs are unique to each drive (they contain factory calibration data which is unique to each drive), and therefore flashing a drive with another drive’s EEPROM should always be a matter of last resort (i.e. to fix a drive if its EEPROM was inadvertently corrupted/deleted when an EEPROM backup of that particular drive is not available)…

Since EEPROMs are unique, flashing a drive with another drive’s EEPROM might lead to the drive no longer operating optimally. How bad things end up being would basically depend on how much different the calibration data from the two drives is.[/QUOTE]

I f**king love you cvs. My little firmware hoarder :P. I’m glad you posted that, as later seeing someone post their own firmware hex’d, i can’t see a more effective way to get worse results.

However, who knows what kind of results ANY non original EEPROM would provide a different drive…at least in my opinion. In saying that, i would never advise ANYONE to use another EEPROM if AT ALL possible, except for perhaps checking to see if the crossflash/firmware change (OEM wise) was effective, or left the drive “bricked” with the light error or otherwise. Following that, figuring out how to get your original EEPROM to work would be goal #1 for me.

[B]ALWAYS KEEP BACKUPS OF FIRMWARES/EEPROMS (ORIGINALS GUYS, ORIGINALS, CLEARLY LABELED WITH ALL INFORMATION)[/B]


I for instance have chosen to label mine like this...

for instance in c:\drivefw\px880sa\px880sa-1.13-ltnflash-5.28.14-fw.bin

Obviously fw.bin would be EEPROM.bin or something else if it was not the firmware. substituting ltnflash with flashu (fu if you want to be funny :P) or df for dosflash. your labeling system is up to you, but i highly recommend 2 things, label them properly, clearly, and DATE THEM IN THE FILE NAME OF THE DUMP. File attitubtes, especially in windows such as "Create Date/Access Date" are rarely accurate enough that i would risk the 3s to date a file manually, in its file name, for bricking a drive. Especially as these drives increase in price and rarity. cvs is as far asi know the current "archiver", if this has changed, i'm sure he knows who you should contact.

[B]Moving on :slight_smile:
[/B]

[QUOTE=blackened2687;2754939][B]HM01[/B], as I have said few times before, I just cut them from a dump of process memory. So, technically it’s not an extraction, it’s ripping.[/QUOTE]

<3

Indeed, I beleive we spoke about this in PM. In my opinion, the alleged “scrambled flashers” are not scrambled, and probably aren’t even encrypted per se as we normally think. Based on what i’ve worked on and used myself int he past utilities (old…may not be able to even find these) such as UPX, with slight hex editing or perhaps a custom version, as well as morphine (UPX/PE section encrypted to prevent unpacking) could easily accomplish these things (binaries going from readable/extractable plain .bin firmwares, to not even readable/“properly” ordered PE Headers. This essentially means what blackened posted, however back in the day there were some methods to remove the protections, i’m sure they have advanced and LiteOn isn’t using freeware/greyware to do this job…Dont we have a resident LiteOn employee? :stuck_out_tongue:

I would very much like to believe that’s probably just a LiteOn (or licensed, who knows, if we could figure this process out, reversing binary/PE compression and some encryptions has been something i’ve done automated before, with a few simple applications i wrote and modified and a python script)

I’d guess that no one at LiteOn (echem) would be at liberty to discuss this, and dollars to donuts all tags/CopyRight tags that would be left after this process were probably removed, or because of the license/usage LiteOn is utilizing this for, were allowed to be omitted from the PE Headers, or even the .text. section of binary flashers. This is perhaps why so far, the methods of “extracting scrambled flashers” has all been via memory dumps, and is not neccesarily 100%, even with the same exact type of flasher but of a different firmware. At least in my experiences…I’m more then happy to jump back in though. C D and E we’re fun…and I’ve gotten no hate mail yet :stuck_out_tongue:

I have a few more tricks up my sleeves yet I think :slight_smile: If nothing else, the more help, the better…

[QUOTE=Albert;2756460]There is nothing important after address 1e0000 in iHBS112 CL0K, iHBS112 PL06, BWU-500S 2.63, BD-W512GSA PT11, or PX-B950SA 1.01. It is just empty space (all 1111… or FFFF…), so I think the differences do not matter; maybe it is just the extra EEPROM information (which isn’t overwritten when doing a normal flash).[/QUOTE]

My only idea is that it could be translated to the equivalent of a NOOP in whatever EEPROM is read as…“empty/void” space yes, whether its contents matter is probably up to the firmware and checksums etc that are verified…stock fw my not read the EEPROM if its 1’s instead of F’s or 0’s or whatever, or it may disregard past a memory address or a certain hex value/string, sort of like 0x00 does in a character array in C, and/or that is just reserved space for future expansion IF necessary.

Alterntively, my other THEORY is perhaps ordering/fabricating some custom sized ROM chips for the firmware and EEPROM was too expensive, so order rounded 1MB or 2MB or whatever, and fill extra space with that till it may or may not be used. I dont know if the EEPROM and FW are stored on the same chip, certainly there appears to be plenty of space to store both on one chip, but that’s probably not “good architecture/security/redundancy/whatever”…does anyone know?

Would love to be able to exploit a drives firmware and use the extra space to execute arbitrary code…like dumping…but i’m sure we will figure out more practical/easier ways before that is even possible.

So sorry for the long post…for those who like TL;DR…here you go.

[B]TL;DR [/B]

posted/wrote original stickied thread for crossflashing C D E successfully, went AFK for months+, barely checked in, have more free time now due to OTHER IRL issues, looking to see where things are at...

P.S. it makes me smile to see people constantly linking to my sticky for instruction/content reference. Glad to be of assistance and provide ANY solutions I can.

Hope all is well in myce club camp. I know this is a long post, and some might not even read the TL;DR and care, but for the few that can fill this much in, what sort of drives are the ones that are needing attention (series, brand, rebadges, anything…check my sig for what I currently have, oh and i need to update it, because i obtained a DH-16A1L just yesterday…and havent even plugged it in yet to see anything about it, even if it works :P)

zak


#110

@[B]zak7

[/B]You can change the calibration data in several types of DVD and BluRay LiteOn models .On this is the case tested positive for ihas x24A, ihas x24B, Liteon iHBSx12. We do this so recently, yet we test everything, but mostly when replacing the OPU to restore factory efficiency. For me and Blackened2687 several times already succeeded on 100% change OPU and laser calibration data.






#111

Hi there, [B]zak7[/B]! Long time no see.

First important thing - SPI flash is embedded into main MTK chip. It seems that there is a way to connect entire board to external programming hardware to work with SPI flash directly (in the case of destroyed firmware, bootcode and eeprom), but I haven’t researched in this direction due to lack of spare time (very busy on my job and often I even barely have time to sleep).

Second thing - so-called “EEPROM” is stored in special area of SPI flash and there is no any separate chip for it. In 2MB flash chips it stored in 1E0000-1FFFFF area, in 1MB flash chips it stored in E8000-FFFFF area. When we read EEPROM with EEPROM Utility or LtnFlash, we get specially-processed piece of data from this area, but I don’t know the algorithm of this.

Third thing - you CAN’T completely overwrite EEPROM area with EEPROM Utility or LtnFlash in standard mode - many areas such as OPU calibration data or the confiruration (?) header will remain the same - that’s why restoring of EEPROM from the dump gotten from different drive will bring you nothing but blinking LED. But you can overwrite full flash of the drive with a full flash dump from another drive, and then additionally upload the eeprom dump from that another drive with EEPROM Utility - then you will get exact copy of that another drive (excluding the OPU calibration data which should be changed in the full flash dump - get proper data from old EEPROM or from a QR code on the bottom label of the OPU).

Fourth thing - DVD-RAM support and LightScribe are also confirured in the EEPROM area (in the header, I believe) - so if you upload full flash gotten from DH-4O1S drive without DVD-RAM support (with CP5x firmwares) into DH-4O1S which had DVD-RAM support (with 2P5x firmwares) and then flash DVD-RAM-enabled firmware into your “new” drive, your drive will report, that it supports DVD-RAM reading, but in fact it will not recognize them. Also, if you have iHAS424 B with wrong EEPROM and blinking LED, and then upload the full flash dump from iHAS124 B into the drive, and then crossflash it into iHAS424 B again, you will get working drive which will report about LS support, and even will recognize LS media, but it will not burn any label - just will imitate the process of labeling - you will just get empty untouched labeling surface.

I excuse if it’s very hard to read - I have very little time - work, work, busy, busy…


#112

[QUOTE=czary2mary1;2757665]@[B]zak7

[/B]You can change the calibration data in several types of DVD and BluRay LiteOn models .On this is the case tested positive for ihas x24A, ihas x24B, Liteon iHBSx12. We do this so recently, yet we test everything, but mostly when replacing the OPU to restore factory efficiency. For me and Blackened2687 several times already succeeded on 100% change OPU and laser calibration data.[/QUOTE]

[QUOTE=blackened2687;2757707]Hi there, [B]zak7[/B]! Long time no see.

First important thing - SPI flash is embedded into main MTK chip. It seems that there is a way to connect entire board to external programming hardware to work with SPI flash directly (in the case of destroyed firmware, bootcode and eeprom), but I haven’t researched in this direction due to lack of spare time (very busy on my job and often I even barely have time to sleep).

Second thing - so-called “EEPROM” is stored in special area of SPI flash and there is no any separate chip for it. In 2MB flash chips it stored in 1E0000-1FFFFF area, in 1MB flash chips it stored in E8000-FFFFF area. When we read EEPROM with EEPROM Utility or LtnFlash, we get specially-processed piece of data from this area, but I don’t know the algorithm of this.

Third thing - you CAN’T completely overwrite EEPROM area with EEPROM Utility or LtnFlash in standard mode - many areas such as OPU calibration data or the confiruration (?) header will remain the same - that’s why restoring of EEPROM from the dump gotten from different drive will bring you nothing but blinking LED. But you can overwrite full flash of the drive with a full flash dump from another drive, and then additionally upload the eeprom dump from that another drive with EEPROM Utility - then you will get exact copy of that another drive (excluding the OPU calibration data which should be changed in the full flash dump - get proper data from old EEPROM or from a QR code on the bottom label of the OPU).

Fourth thing - DVD-RAM support and LightScribe are also confirured in the EEPROM area (in the header, I believe) - so if you upload full flash gotten from DH-4O1S drive without DVD-RAM support (with CP5x firmwares) into DH-4O1S which had DVD-RAM support (with 2P5x firmwares) and then flash DVD-RAM-enabled firmware into your “new” drive, your drive will report, that it supports DVD-RAM reading, but in fact it will not recognize them. Also, if you have iHAS424 B with wrong EEPROM and blinking LED, and then upload the full flash dump from iHAS124 B into the drive, and then crossflash it into iHAS424 B again, you will get working drive which will report about LS support, and even will recognize LS media, but it will not burn any label - just will imitate the process of labeling - you will just get empty untouched labeling surface.

I excuse if it’s very hard to read - I have very little time - work, work, busy, busy…[/QUOTE]

I don’t have any trouble reading your writing even though iirc english is not your first language, <3

Anyway - Thanks for updating me on the new “methods”, the third and 4th thing specifically, the first two i mostly knew all of. Great refresher though! for firmwares/eeproms on the liteon drives, last time i was active, we didn’t know the calibration data/OPU data stuff yet. Bravo blackened and czary2mary1 (i assume you guys worked together on this by czary2mary1’s post).

The method you are talking about for reading the chips/board (your first thing) directly is probably a regular JTAG method, which would require creating a (likely serial) connection to the board directly, soldering some leads stripped from the cable onto specific parts of the board, and then establishing a raw telnet session or something to the board. I’ve jtagged XBOX360’s as well as done some work on the galaxy series (cell phones) and reading DART info, etc as well as linksys routers/unbricking all of the above (except xboxes obviously, those rrod’s were a different method.)

This is definitely something that with the right documentation I could assist in, however its likely only the beginning when we establish a connection the board.

I’d fully expect custom commands, no help command, and probably no responses untill you get the commands right. Liteon seems to have gone in that direction at least, “scrambling” the flashers fw’s and all that. I’d be very suprised that we get something out of them by JTAG’ing them. If there was a exploit or way to dump the firmware, for instance with a series of vendor mode intro’s and ejecting the cd tray (this is how the XBOX360 liteon drives are dumped, i’ve tried fooling around with replicating this method on the non-xbox360 liteon drives, and it failed to work thus far, but of course i fully expected that with microsoft having custom firmwares on the 360, and liteon pairing up with another manufacturer for the xbox drive as well made me doubt it would work.

Sorry for the rambling…but there are just so many possibilities as you know :stuck_out_tongue: Too bad we haven’t found the perfect one to continue our quest yet.

What we really need to do is get someone like codek1ng back to start cooking up new firmwares and feature enhancement for our current drives, that to me is the big peice we are missing.

Perhaps i’ll look into reverse engineering firmwares, or decompiling them, and study up on my assembly again. I’m way to rusty to be doing any of this right off the bat lol!

i wish i could write firmwares. or even mod them! think that will be what i start researching next.


#113

[B]zak7[/B], I’ve never tried JTAG on any optical drive :wink: Proper full flash dump is produced by DosFlash and by LtnFlash in SFlash mode. As for me - I prefer LtnFlash. :slight_smile: Also LtnFlash in SFlash mode can easily rewrite full flash with new dump. No need for JTAG in this case.


#114

Great to see some really talented people in this thread, working on this.

I spent a lot of time going through the firmware and found commands that Liteon never wanted anyone to know about. Undocumented factory commands that require complex encryption to activate. In respect to Liteon, I kept most of these commands secret and for my own use.

I did one more special version of the Eeprom Utility that encorporated one of these commands, but before it was released I left cdfreaks, vowing to never return.

However, I can see now that this version could really help by eliminate the need to use a hex editor and even avoid knowing the eeprom code number for the drive.

When I get time I will try to find it in my archives, host it and post a link. Hopefully it still works with the new generation of drives…


#115

[B]C0deKing[/B], thank you for your amazing work! Your utilities and patched firmwares helped a lot of people (including me) to experience all the potential of LiteOn drives. :clap: :bow: :flower:

It’s great to see you in this topic and read these words from you. :slight_smile: I’ve tried to figure out EEPROM convertation algorithm (changing 1-byte values at 0x100, 0x105, 0x10A, 0x10F and checksum in the end of EEPROM image), and to understand EEPROM data structure - but still without success. :slight_smile: OPU calibration data is the most valuable thing we’ve figured out.

LiteOn drives are very hard nuts, when it comes to crossflashing, repair or something else…


#116

Thank you for your kind words, blackened. I can see you’ve done some excellent work here, as well. :clap:

I was expecting a bit more interest when I came back here today. Perhaps no one is interested in the enhanced version. Oh well…


#117

I am very much concerned, are willing to donate a kidney for enhanced version …:wink:


#118

[B]C0deKing[/B], it seems that’s because the people’s interest to optical drives faded dramatically in last 2-3 years. :frowning: I think that people who are still active here and drive collectors/enthusiasts (like me or [B]czary2mary[/B]) would be very interested in enhanced version. Possibility of crossflashing iHAS120/122/124 -> iHAS324/524 on newer revisions would be great - for example in Russia there is no possibility to buy any iHAS324 officially - only 122/124 are sold here, so I’m very interested in it. :iagree::clap::clap:

Right now I’m working on the flashing utility for Pioneer drives - and even if there will be same weak interest to it, I will still release, update and maintain it. Some people want it - and I’ll release it for them. :slight_smile:

I’m looking forward to any new tools from you, [B]C0deKing[/B]! :clap::clap::clap:


#119

I am also waiting in line for novelty … great news - Return of the King swept the LiteOn … very very’m happy - looking forward
I look forward to the new soft from you [B]C0deKing[/B].:clap::clap::clap::clap:


#120

[QUOTE=C0deKing;2759345]Thank you for your kind words, blackened. I can see you’ve done some excellent work here, as well. :clap:

I was expecting a bit more interest when I came back here today. Perhaps no one is interested in the enhanced version. Oh well…[/QUOTE]
Updated/enhanced versions of your utilities would be most welcome. :cool:

There are still a few of us bona fide CDFreaks left who still appreciate [I]all[/I] your hard work over the years and mourn your departure. :flower::flower::flower:

What are you doing these days?


#121

[QUOTE=C0deKing;2759189]I spent a lot of time going through the firmware and found commands that Liteon never wanted anyone to know about. Undocumented factory commands that require complex encryption to activate. In respect to Liteon, I kept most of these commands secret and for my own use.

I did one more special version of the Eeprom Utility that encorporated one of these commands, but before it was released I left cdfreaks, vowing to never return.

However, I can see now that this version could really help by eliminate the need to use a hex editor and even avoid knowing the eeprom code number for the drive.

When I get time I will try to find it in my archives, host it and post a link. Hopefully it still works with the new generation of drives…[/QUOTE]

Wonderful to hear from you, CodeKing! You’re still our hero! :bow:

Any help/advice/updated utilities you can provide would be welcomed by all of us. Ibex is spot on in saying how much we appreciate all the efforts you put in over the years. :iagree: