• Please review our updated Terms and Rules here

Unlocking older LSI Disk Arrays to support 3RD party disks.

G

GrizzlyAdams

Member
Joined
Apr 10, 2016
Messages
13
So thanks to a good buddy, I now am the lucky owner of four LSI fibrechannel disk arrays of varying vintage.

Sadly, almost all of them were locked to only recognize the matching branded drives. The IBM DS4100 would only accept drives approved by IBM, the SGI IS220 would only take drives approved by SGI, etc.

For the IBM DS4100, it was easy enough to follow the directions on hddguru to create a script that set driveSignMode=0 at every boot.

The SGI IS220 however was lacking the driveSignMode symbol, being that it runs a much later firmware build.
Digging in, I managed to use binwalk to split the firmware update for the enclosure to its constituent files, one of which 'MfgConfig' matches the SubModelID (stored in the 'MfgSec' NVSRAM page) and turns various features on/off, sets which drives and shelfs the controller will talk to.

NOTE: I use some placeholder text 'xx' where you will have different values, and zeros for my serial number.
  • You will also have different addresses for NVSRAM pages.
  • I'm not responsible for you bricking your disk array.
  • If you don't know what you are doing, can't think for yourself, etc.
  • Do not do this on production systems.
  • You need serial shell access to the controller(s), which is documented elsewhere.

So we need to change the first byte of the 'MfgSec' page, but the Boot Operations Menu has that page locked out for editing, instead hiding it behind the Manufacturing Setup Menu and another mysterious password that I don't have the tools or spare time to go digging for.

Since we have a dump of all the firmware blobs, we can run strings on the main firmware and look around for some useful symbols, and that is where I found my new friends.
  • sysNvsramShow - gives us the address in ram for the shadow copy of NVSRAM
  • sysNvsramUnlockAll - unlocks the shadow copy for editing
  • sysNvsramCommit - writes the shadow copy to the NVSRAM chip
These, along with the d and m commands of the shell let us modify the NVSRAM contents, bypassing the Manufacturing Setup Menu.
Starting at the base address shown by sysNvsramShow (0x88480000 in my case) we use
Code: 
-> d 0x88480000,1024,1
to dump the memory until we find the MfgSec page.
Code: 
0x884848c0:  fa fb 4d 66 67 53 65 63 00 00 xx xx xx xx 40 00  *..MfgSec..XXXX@.*
0x884848d0:  5f 00 00 00 30 30 30 2d 30 30 30 30 30 30 30 00  *L...000-0000000.*
0x884848e0:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  *................*
0x884848f0:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  *................*
0x88484900:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  *................*
Each page of NVSRAM starts with bytes FA FB, then the 8-byte page name (zero padded), a checksum, then the size of the page.
We want to change the byte 5F, which corrisponds to 95 decimal, or "Accent T3" from the MfgConfig file. Depending on your controller, this value will vary, and the contents of MfgConfig will vary as well.
Here is where I hit another stumbling block, the checksum. Rather than bother figuring out what checksum algorithm was used, I took advantage of the ability to edit some other pages in the NVSRAM easily.
Code: 
-> M
                           BOOT OPERATIONS MENU

 1) Perform Isolation Diagnostics    10) Serial Interface Mode Menu
 2) Download Permanent File          11) Display Hardware Configuration
 3) Reserved                         12) Change Hardware Configuration Menu
 4) Dump NVSRAM Group                13) Development Options Menu
 5) Patch NVSRAM Group               14) Display Memory Error Log
 6) Set Real Time Clock              15) Manufacturing Setup Menu
 7) Display Board Configuration       R) Restart Controller
 8) Special Services Menu             Q) Quit Menu
 9) Display Exception Message

    Enter Selection: 5
This gets us to the very helpful NVSRAM patching menu, which of course is missing MfgSec.
Code: 
   NVSRAM GROUPS TO PATCH

 1) Board       29) H3UsrCfg
 2) NonCfg      30) H4UsrCfg
 3) Platform    31) H5UsrCfg
 4) UserCfg     32) H6UsrCfg
 5) HostData    33) H7UsrCfg
 8) SubSys      34) H8UsrCfg
 9) DrvFault    35) H9UsrCfg
10) InfCfg      36) H10UrCfg
11) RDAC        37) H11UrCfg
19) DevSupp     38) H12UrCfg
20) SubSysID    39) H13UrCfg
21) FCCfg       40) H14UrCfg
25) ExtUCfg     41) H15UrCfg
26) H0UsrCfg    49) DrvExpMg
27) H1UsrCfg     Q) Quit Menu
28) H2UsrCfg

    Enter Selection: 41
So then we can copy our serial number and the SubModelID we desire into H15UrCfg and the firmware will helpfully calculate a checksum for us. You will want to change H15UrCfg back to its initial values when you are done patching MfgSec.
Code: 
Enter offset in 'H15UrCfg': 0

H15UrCfg+0x00: 57  4c
H15UrCfg+0x01: 32  00
H15UrCfg+0x02: 4B  00
H15UrCfg+0x03: 4E  00
H15UrCfg+0x04: 45  30
H15UrCfg+0x05: 54  30
H15UrCfg+0x06: 43  30
H15UrCfg+0x07: 4C  2d
H15UrCfg+0x08: 44  30
H15UrCfg+0x09: 4D  30
H15UrCfg+0x0A: 50  30
H15UrCfg+0x0B: 00  30
H15UrCfg+0x0C: 00  30
H15UrCfg+0x0D: 00  30
H15UrCfg+0x0E: 00  30
H15UrCfg+0x0F: 00  00
H15UrCfg+0x10: 00  00
H15UrCfg+0x11: 20  00
H15UrCfg+0x12: 00  00
H15UrCfg+0x13: 00  00
H15UrCfg+0x14: 01  00
H15UrCfg+0x15: 00  00
H15UrCfg+0x16: 00  00
H15UrCfg+0x17: 01  00
H15UrCfg+0x18: 00  00
H15UrCfg+0x19: 01  00
H15UrCfg+0x1A: 01  00
H15UrCfg+0x1B: 01  00
H15UrCfg+0x1C: 00  00
H15UrCfg+0x1D: 00  00
H15UrCfg+0x1E: 00  00
H15UrCfg+0x1F: 00  00
H15UrCfg+0x20: 00  00
H15UrCfg+0x21: 00  00
H15UrCfg+0x22: 01  00
H15UrCfg+0x23: 01  00
H15UrCfg+0x24: 01  00
H15UrCfg+0x25: 80  00
H15UrCfg+0x26: 00  00
H15UrCfg+0x27: 08  00
H15UrCfg+0x28: 00  .

Commit changes to NVSRAM? (y/n)  y


NVSRAM changed
    Press <Enter> to continue
Only some of the bytes in H15UrCfg had to be patched, since the last 24 bytes were already zero.
now we can dump the contents of H15UrCfg (you should have passed it's location earlier when searching for MfgSec...)
Code: 
->  d 0x88482240,80,1
88482240:  fa fb 48 31 35 55 72 43 66 67 xx xx xx xx 40 00   *..H15UrCfgXXXX@.*
88482250:  4c 00 00 00 30 30 30 2d 30 30 30 30 30 30 30 00   *L...000-0000000.*
88482260:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   *................*
88482270:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   *................*
88482280:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   *................*
So now, we just need to copy bytes 0x0A-0x10 (the checksum and the first byte of the data section) to MfgSec we found earlier, commit the write to the chip, and reboot! Remember that your address WILL most likely be different than mine.
Code: 
->  m 0x884848c0,1
884848ca:  xx-xx
884848cb:  xx-xx
884848cc:  xx-xx
884848cd:  xx-xx
884848ce:  40-40
884848cf:  00-00
884848d0:  5f-4c
884848d1:  00-.

value = 1 = 0x1
->  sysNvsramCommit
value = -1 = 0xffffffff
->  sysNvsramLock
value = 0 = 0x0
->  sysReboot
-=<###>=-

Hopefully at this point you should have success!
 
And I've just completed this on another controller-drive shelf, so I've converted an SGI IS220 to an unbranded DS3200, and an SGI IS500 to an unbranded DS4200. For the IS500/DS4200 (LSI 3992 Controller) the magic value was 0x71 to unlock the drive signing.
 
GrizzlyAdams said:
And I've just completed this on another controller-drive shelf, so I've converted an SGI IS220 to an unbranded DS3200, and an SGI IS500 to an unbranded DS4200. For the IS500/DS4200 (LSI 3992 Controller) the magic value was 0x71 to unlock the drive signing.
Click to expand...

so what is command to sign the drive for 3rd party hard disk
 
Hello.

I would like to ask you several questions about procedure you described.
I have several controllers E2600,E2700,E5400,E5500 in my infrastructure
Based on your procedure i made successful changes of Submodel ID 180 of my controllers E2600A-2GB-R6 from basic value 4d to value 78 349-5481900 (Submodel ID 134).
However, after these changes i got array with manufacturer Teradata and ID 134. This configuration allow me to use my disks, but i totally lost several important options like (Thin Provision, ssd cache, SANshare Storage Partitioning) as my array now has no licenses.
I tried to use your "magic value" 0x71, but has no success. My array reported about incorrect ID and failed to boot.

So i have several questions:
1. Do you have arrays with same controllers as i have? If yes - did you successfully unlock disks on these arrays? And if so - did you still licenses for additional features?
2. Can you provide some information about possible byte values for my array?
3. I found link on Github - https://github.com/jmrunkle/Support-Bundle/blob/master/storageArrayProfile8.txt. Here i saw model Teradata Turbo with Submodel ID 97. Do you know how to get this value with procedure you deswcribed?

With best regards
 
GrizzlyAdams, thank you for information, using it i just could patch my DS3500 storage.
But i found a little easier way to change submodelID in the document "DS5K Controllller shows SubModMiis Lockdown error" :
There are commands sysCfgShow 1 that print out part of NVRAM with SubmoduleID information and sysCfgInstallStream 1 that could write to NVRAM that area with new values,
Example from that doc:
Type the following:

-> sysCfgShow 1
# Automatically generated
MfgSec + 0 = 0x5d,0x00,0x00,0x00
MfgSec + 4 = 0x34,0x39,0x59,0x34,0x31,0x33,0x34,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
value = 0 = 0x0
Click to expand...
sysNvsramUnlock
sysCfgInstallStream 1
Click to expand...
<copy output of sysNvsramShow 1 into it> and hit <control>+<D> wait some seconds, it leaves
automatically.
Click to expand...
Type the following:
sysNvsramLock
psvClearSodRebootLoopCounter
clearHardwareLockdown
lemClearLockdown
Click to expand...

So you could change SubmoduleID, here it's 0x5d and paste result in sysCfgInstallStream 1 command input.
After reboot i get wrong SubmoduleID error, but after power off\on controller startup normally.
 
Last edited:
You must log in or register to reply here.
Back
Top