IBM BB4A MuskiePlus — Real Capacity Lock Found (Module 01)

[gurunicewh]

Hi everyone,

I'm the guy who was asking about Module 03 for the IBM ST160NM0011 (MuskiePlus, BB4A) a while ago. I've done a lot of digging since then and finally found the real source of the capacity lock. Now I need help with the final step.

What I discovered:

The 160GB limit is NOT in Module 03, not in HPA/DCO, and not in MAT flags. It's hardcoded into Module 01 (the main firmware overlay).

The 160GB constant 0x12A0F240 (312,537,664 sectors) appears six times in the ARM code of Module 01.

I patched all six occurrences to 0x3A386030 (500GB, 976,773,168 sectors). The patched Module 01 and a full patched LOD file are ready.

The problem:

IBM firmware BB4A blocks writing Module 01 via terminal (w01 hits a buffer limit at ~108 KB).

Command D (Download) is completely blocked by the IBM overlay.

I tried patching the ROM directly via CH341A, but the bootloader CRC check prevents the drive from spinning up.

What I need:
An unlocked ROM (Tech Mode Unlock) for this drive, so that the D command becomes available in the terminal. Alternatively, a ROM with CRC/signature checks disabled for Module 01.

What I have:

Original ROM dump (dump_1.bin, 512 KB, LE25FU406B)

Patched Module 01 (mod01_500gb_patched.bin)

Full patched LOD (MP-SN03_500gb_patched.LOD)

CH341A programmer ready

If anyone with PC-3000 can run my ROM dump through the "Unlock ROM" / "Tech Mode Unlock" function, or share an unlocked ROM for MuskiePlus BB4A, I'd be extremely grateful. This is a matter of principle now — the drive deserves to see its native 500GB.

Thanks to everyone who helped in the previous thread. We're almost there.

Attachments

dump_1.zip

dump_1.bin

(257.74 KiB) Downloaded 6 times

[E123]

We're almost there.

Yes. Somewhere like this in several years of intensive reverse engineering. "Through thorns to the stars." Have you tried downloading the firmware I provided?

[gurunicewh]

Yes, I did. Thank you again for that file — it was the foundation for everything that followed.

I extracted the firmware, reverse-engineered Module 01, found the six occurrences of the 160GB constant (0x12A0F240), and patched them to 500GB (0x3A386030). The patched Module 01 and a full patched LOD are ready.

The problem now is that BB4A blocks the write: w01 hits a buffer limit, command D is blocked by the IBM overlay, and direct ROM patching fails due to CRC protection on the bootloader.

So I'm stuck at the last step — I need an unlocked ROM (Tech Mode Unlock) to bypass these restrictions and flash the patched firmware. That's what I'm asking for in this thread.

Your file opened the door. I just need the key to walk through it.

[gurunicewh]

You mentioned "several years of intensive reverse engineering." If you don't mind me asking:

1. Is there any way to bypass BB4A terminal write protection without PC-3000?
2. Are there any hidden commands to temporarily disable signature verification?
3. Any advice on patching the ROM so the CRC doesn't reject it?

I feel like I'm one step away. Any hint would be invaluable.

[fzabkar]

Upload your original and modified .LOD files and I'll recalculate the CRC for you.

[gurunicewh]

Hi Fzabkar,

Thank you for the offer! Here are the original and modified .LOD files as you requested: 1. MP-SN03.LOD (Original IBM firmware package) 2. MP-SN03_500gb_patched.LOD (My modified package)

What I modified in the .LOD: I found that the 160GB LBA limit (0x12A0F240) is hardcoded in 6 different places inside Module 01. I hex-edited all 6 occurrences to 0x3A386030 (500GB). However, flashing it via SeaChest failed, presumably because of the broken LOD checksums.

I have also attached my ROM dumps just in case: 3. dump_1.bin (Original 512KB ROM) 4. dump_1_500gb_patched.bin (Modified ROM)

What I tried with the ROM: I patched the base capacity constant 0x12A0E6F4 in the DL_BFWCTNR segment to 0x3A386030. But after flashing it via CH341A, the drive refused to spin up, likely due to a Bootcode CRC mismatch. F3RomExplorer (free version) couldn't recalculate the Bootcode sum for this MuskiePlus drive.

If you can fix the CRC for the .LOD file so I can flash it via ATA, that would be amazing. Alternatively, if providing a "Tech Mode Unlock" patch for my ROM (so I can use the terminal 'D' command) is easier, I'm ready to go that route too.

Thanks again to you, e123, for guiding me through this puzzle. We are so close to breaking this IBM lock!

Attachments

files 2.zip

(515.49 KiB) Downloaded 6 times

files.zip

(1.65 MiB) Downloaded 5 times

[E123]

Upload your original and modified .LOD files and I'll recalculate the CRC for you.

All great adventures began with the phrase: “I know a shortcut.” Keep burning, Frank. (There are only two bits that need to be changed, but the "Russians are not looking for easy ways" either.)

[gurunicewh]

Hi Frank,

Just a gentle follow-up on the LOD and ROM files I uploaded on May 23rd. I hope they didn't get buried in the thread.

Whenever you have a moment, I'd be grateful for any help with the CRC recalculation. No rush at all — I know you're busy, and I really appreciate you taking the time to look into this.

Thanks again

[fzabkar]

Sorry, I saw the reply by @E123, but I could swear that yours was not visible at that same time.

Anyway, you can recalculate ROM CRCs using F3RomExplorer (written by @E123):

https://www.hddoracle.com/viewtopic.php?p=18531#p18531

Double-click the BFWCNTR segment to expose its component segments, then right-click the desired segment and select "Recalculate CRC" from the menu.

This tool extracts the components from the .LOD file:

https://www.hddoracle.com/viewtopic.php?p=15087#p15087

This tool can recalculate the CRC:

https://www.hddoracle.com/viewtopic.php?p=15002#p15002

Just specify "-recalc" on the command line. The tool assumes that the CRC is at the end of the file.

My tools run inside a CMD window under Windows.

[gurunicewh]

Hi Frank,

A quick update on the ROM patching. I followed your instructions and fixed the CRC on the patched ROM using the Seagate CRC16 algorithm. The internal BFWCNTR checksum and the global file checksum are now correct.

Here's the interesting part: with the earlier patched ROM (before CRC fix), the motor at least tried to spin up — there was some activity. But with the corrected ROM, it's completely dead — no motor movement at all, total silence. This suggests the CRC check is now passing, but a deeper security layer (likely RSA/Secure Boot) is blocking the boot even harder.

Is there a known "Unlock ROM" patch or a way to disable the RSA check for this specific MuskiePlus BB4A firmware? I've attached the fixed ROM for reference.

Thanks

Attachments

dump.zip

(257.77 KiB) Downloaded 5 times

[fzabkar]

Sorry, I can't help you.

[gurunicewh]

Hi Frank,

Sorry to bother you again. I discovered something odd and just wanted to share the facts.

Here's what happened:

· Patched the capacity constant in ROM (160GB → 500GB).
· First patch (only the constant changed, CRCs left untouched): motor spun up, terminal was alive, drive reported diag error 00000024 on r03, but it was responding.
· Second patch (constant changed + internal BFWCNTR CRC recalculated + file padding fixed): motor doesn't spin up at all. Complete silence.

So the version with correct checksums behaves worse than the one with incorrect checksums.

Question: why would fixing the CRCs prevent the motor from spinning up, when leaving them broken allowed it to start? What am I missing?

I've attached both ROM files for reference.

Thanks for any insight

[fzabkar]

There are two BFW Containers, 0 and 1. Container 0 is the active container, container 1 is inactive. I suspect that a CRC error in container 0 causes the MCU to boot from container 1. After correcting the CRC in container 0, you would then be facing a coding error that you introduced with your edit.