Need Module 03 (VBAR) dump for ST500NM0011 BB4A - IBM OEM un

[gurunicewh]

Hello,
I need Module 03 (Zone Table / VBAR) dump from:
- Model: Seagate ST500NM0011
- Firmware: BB4A
- NOT IBM OEM (need genuine Seagate version)
- PCB: same family as IBM ST160NM0011 (MuskiePlus/Broadway architecture)
My drive: IBM OEM ST160NM0011 (physically ST500NM0011)
ROM MD5: 375AFE6E34CF5D2C7D1179BC8E65D1BE
Serial: Z1M0QFXN (prefix)
I have F3 terminal access and CH341A programmer.
ROM is already patched to allow Module 03 write access.
Only need the 500GB Zone Table data to write.
Thank you!

Attachments

dump.zip

(257.74 KiB) Downloaded 12 times

[pepe]

Hello,

module 03 contains plist, which is unique to the drive (and not even necessary for drive operation), I can't see how you could be helped out with such file.
On the other hand, zone table is also unique, so replacing that is not an option either.
Anyway, you wrote quite some pointless things but not the problem and the symptoms itself.

[gurunicewh]

[quote="pepe"]Hello,

Thank you for the clarification. It seems I may have been using incorrect module numbering. Some utilities (like STComTools) label the Zone Table as Module 03, but in the actual F3 architecture, the Zone Table (VBAR / Format Parameters) is more likely Module 0B.

So let me correct my request:

I am looking for Module 0B (Format Parameters / Zone Table / VBAR) from a donor ST500NM0011 with firmware BB4A (MuskiePlus family).

My goal is the same — to see the correct 500GB zone layout (zones per head, cylinders per zone, sectors per track) so I can rebuild a valid Zone Table for my IBM-crippled ST160NM0011.

I have already patched the ROM Module Access Table to bypass the IBM Vendor Lock (LED:000000EE → diag error 00000024). The drive now attempts to access SA modules, but the Zone Table itself has an IBM-specific truncated structure.

Any help would be greatly appreciated. Thanks again for the correction!

Last edited by gurunicewh on May 19th, 2026, 8:15, edited 1 time in total.

[gurunicewh]

Here's a quick summary of what I'm doing and where I got stuck.

The drive:

IBM OEM ST160NM0011, physically ST500NM0011 (MuskiePlus, firmware BB4A)

Artificially short-stroked to 160GB via truncated Zone Table

Heads are healthy, P-List shows defects up to 39D904EE

What I've done so far:

Got F3 terminal access via TTL (PuTTY, 38400 8N1)

Changed drive identity to 500GB via STComTools (Lbas = 3A386418 confirmed)

Dumped ROM via CH341A (LE25FU406B, 512KB)

Analyzed ROM, found Module Access Table (Copy A @ 0x19000, Copy B @ 0x58E4C)

Patched MAT: changed byte 0x08 to 0x00 for the Zone Table entry (at 0x19038 and 0x58E50)

Flashed patched ROM back

Result of the patch:

Before: any attempt to access Zone Table → LED:000000EE (access denied at ROM level)

After: access attempt → diag error 00000024 (ROM lock removed, but module fails validation)

Where I'm stuck:
The IBM-crippled Zone Table (VBAR / Format Parameters) has invalid structure (truncated to 160GB). I can't read it via terminal (returns 0x24), can't use Level 2 (blocked), alternative SA copies return "skipped".

What I need:
Module 0B (Format Parameters / Zone Table / VBAR) from a donor ST500NM0011 with firmware BB4A (MuskiePlus family). This will let me see the correct 500GB zone layout and rebuild a valid Zone Table for my drive.

(Note: I previously referred to this as "Module 03" based on STComTools numbering, but in F3 architecture it appears to be Module 0B. Thanks for the correction.)

Thanks for any help!

[pepe]

there is no such thing as zone table in the classic meaning in F3 seagates, zone vbar data is in RAP, not in the SA. Quite some dynamic tables are built from tables in rap during init.
I think, if zones were disabled RAP zone count would reflect that, however it is just normal in your rom... What is the point? restore 500G capacity? that would be crazy

[fzabkar]

Could this capacity truncation be a simple case of HPA, or a DCO limitation? If so, then HDAT2 can handle both.

[gurunicewh]

there is no such thing as zone table in the classic meaning in F3 seagates, zone vbar data is in RAP, not in the SA. Quite some dynamic tables are built from tables in rap during init.
I think, if zones were disabled RAP zone count would reflect that, however it is just normal in your rom... What is the point? restore 500G capacity? that would be crazy

Thanks for the clarification regarding RAP! You are absolutely right. The fact that the full 500GB zone parameters are already sitting in the ROM and aren't cut down is actually great news for me. It means I won't have to build a Frankenstein out of donor SA modules.

As for "what is the point" — it's pure academic curiosity and reverse engineering. I completely understand that for commercial DR this is crazy and a waste of time, but this is a pet project specifically to study the F3 architecture and bypass IBM's vendor locks.

By the way, a quick update on the Vendor Lock bypass. I tried to patch overlays 0x22 and 0x23 in the ROM (cleared the 0x08 lock flag at 0x19038 and 0x58E50). To bypass the checksum, I used a 32-bit aligned byte compensation method (moved 0x08 to an empty padding area with a mod 4 offset). This successfully tricks any basic SUM/XOR checks, but the drive still threw diag error 00000024.
Conclusion: The controller uses a strict polynomial CRC (likely a custom CRC-16 CCITT) for the overlays. The ROM wall is solid.

So, I'm abandoning the direct ROM patch and moving to Plan B: hardware bypass. I'm going to short the SPI Flash (Pin 2 DO to GND) at power-on to drop the Marvell into Boot 0x20M, and then upload an LDR into RAM via Y-Modem. That should give me full SA access, bypassing the ROM locks entirely.

Two questions for the gurus here:

Has anyone ever reversed the exact CRC polynomial and seed used for F3 overlays? Just out of academic curiosity.

Does anyone happen to have a compatible Loader (LDR) file for MuskiePlus (ST160NM0011) handy, so I don't have to extract it from an official .lod update?

[gurunicewh]

Could this capacity truncation be a simple case of HPA, or a DCO limitation? If so, then HDAT2 can handle both.

Thanks for the tip! That would be the easiest fix, but unfortunately, it's definitely not HPA or DCO.

First, the drive identifies itself natively as ST160NM0011 in the ATA passport, meaning the model string and capacity limits are hardcoded deep inside the firmware, rather than just clipped via standard ATA commands.

Second, and more importantly, we are dealing with a firm-level restriction inside the Seagate F3 serial terminal (F3 T>). Standard ATA tools like HDAT2 or MHDD operate via standard SATA commands and cannot interact with the F3 subsystem. They certainly can't bypass the Vendor Lock flag (0x08) embedded in the ROM MAT (Module Access Table) overlays, which is what's currently blocking terminal commands like r03 and throwing diag error 00000024.

This is a hard vendor lock (common for OEM drives made for IBM/Lenovo), so standard utility software won't help here. Only LDR injection or ROM patching can pierce through this.

[SWM]

Sorry, deleted. Didn't check where they were asking from...

[gurunicewh]

Hey,

I saw you deleted your reply. Did I break some forum rule? Just wanted to check — I'm new here and don't want to cause any trouble.

[E123]

It's IBM's feature. It may be solved by different ways. If you are no need in IBM's fw and have possibility to change firmware, change it to generic, then recalculate translator. (Sorry, I was inattentive, it looks like you can’t.)

[E123]

Try this .lod

Attachments

MP-SN03.7z

(730.24 KiB) Downloaded 12 times

[gurunicewh]

Try this .lod

Hey,

Just wanted to say thank you for the MP-SN03.LOD file. I'm currently trying to extract what I need from it and working on getting it written to the drive.

Really appreciate your help — this was the missing piece I've been hunting for weeks. I'll update the thread when I get the drive fully unlocked.

Thanks again