Re: Load source on old 9406-720

There is an option to copy to load source to an unassigned drive, but
do remember that AS400 harddisks have 522 bytes per sector, i wonder
how the hell you got linux to work with that, was it very very low
level operations?
I'm extremely interested in what you are doing, since i'm a hardware guy.
Continue keeping us posted

best regards,

roberto

On Thu, Apr 12, 2012 at 6:24 PM, Jim Donoghue <jdonoghue04@xxxxxxxxx>
wrote:

Not all is lost. And, I need some help understanding how these disks are
configured.

First, the 'failed' load source drive. For the time being, it's not

failed.

There were two bad blocks on the device, and I was lucky enough to have a
good copy of the drive before it failed. I used the 'sg_reassign' command
(part of a Linux SCSI package) to reassign the two bad blocks. Then, I
copied the good blocks back on the drive. Put the drive back in, and it
IPLs.

So, I poke around in DST. There is 1 ASP with seven drives. For some
reason, I thought there were two ASPs (one with 2 drives and the other

with

5). The entire thing is 95% full.

Now, I consider getting a spare drive and making it a copy of the first
drive. The big question: if I replace the drive and it's contents are
identical, is it going to care? Or will it fail because the new drive's
serial number isn't the same?

Or, is there a way to add the blank drive to the system and move the load
source to it, then make it the new load source device?


Jim

On Thu, Apr 12, 2012 at 2:25 PM, Jim Donoghue <jdonoghue04@xxxxxxxxx>

wrote:

Well, that would have been a fun experiment, but it's not going to

happen.

When I got home this afternoon, tried to IPL the system and get a SRC
27419000. It turns out the other half of what used to be the load source
mirror is now bad. The drive in the first slot has an unrecoverable read
error, and the one in the second slot has a recoverable read error. (I
determined this by attempting to read them using SCSI tools on the PC).

Perhaps I should have left it at the scrap metal place.

Jim


On Thu, Apr 12, 2012 at 12:16 PM, Jim Donoghue <jdonoghue04@xxxxxxxxx

wrote:

It may not matter about the password after all. I can log in as
'22222222', but as I mentioned eariler, the function I need is

restricted.

There is a record for each DST user ID that contains a list of

functions

that the user is allowed access to. I may be able to make the

'22222222'

user's entry have the function I need. I found some interesting areas

on

the disk during lunch, an audit log and the list of DST user profiles:
'SecServiceUserProfile' and 'SecPrivilegeList'. Interesting stuff.

Jim



2012/4/12 Roberto José Etcheverry Romero <yggdrasil.raiker@xxxxxxxxx>

What both of you mean, is. There is usually no way to derive the
password from whatever the OS stores, in linux's case its a shadow
file aka mathematical hash of the password.
I would just pop a lic cd and install, but it is technically a breach
of the os licence. And i believe it's next to impossible to buy a key
for such an old system.

Best regards,

PD: you are better off buying a 520 off ebay with the os key, i have
one, no client access and the such, but it does work.


On Thu, Apr 12, 2012 at 12:03 PM, DrFranken <midrange@xxxxxxxxxxxx>
wrote:

I disagree, they are certainly stored. Were they not stored you

could

not log in. And they must be on disk because I can pull a set of

drives

lock them into another machine, fire them up and sign on. Just did

that

this week with a set of drives from last year's COMMON conference.

Now stored in clear text, of course not. They are encrypted (one way
only) and then stored, but they or at least a representation of them

are

in there.>
- Larry "DrFranken" Bolhuis

On 4/12/2012 10:44 AM, Mark S. Waterbury wrote:

Jim:

Passwords are never stored permanently (on disk) in OS/400 or IBM i

(or

in most any other modern operating systems).

Instead of using "22222222", try using "QSECOFR" as the DST userID.

Cheers,

Mark S. Waterbury

> On 4/12/2012 9:49 AM, Jim Donoghue wrote:

The machine was 'rescued' from the scrap metal place. I can log in

to DST

with 22222222, but can't access the option necessary to change the

QSECOFR

password. I think this machine has V4R3 on it.

I think I am going to have to write some tools to hack around with

an image

file from the load source disk. I have a hex editor I wrote that

will

display the EBCDIC characters. What I am thinking of doing is

grabbing two

images of the disk - one as-is, and a second one after I change

the

password for the DST user 22222222. Then maybe I can find where

the

passwords are stored.

Jim

On Thu, Apr 12, 2012 at 8:42 AM, Jerry C. Adams<midrange@xxxxxxxx

wrote:

I'm guessing that the QSECOFR password wasn't included either

when

he

bought
the machine. A company that I worked for years ago had the same

problem:

No
QSECOFR password. But we booted the system into DST and used

either the

22222222 or 11111111 profile to change the password for QSECOFR.

That was,

if I remember correctly, a V3 something machine.

Jerry C. Adams
IBM i Programmer/Analyst
Sir, you have tasted two whole worms; you have hissed all my

mystery

lectures and been caught fighting a liar in the quad, you will

leave Oxford

by the next town drain. - Rev. William Spooner
--
A&K Wholesale
Murfreesboro, TN
615-867-5070

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim

Oberholtzer

Sent: Thursday, April 12, 2012 8:18 AM
To: Midrange Systems Technical Discussion
Subject: Re: Load source on old 9406-720

Your chances of finding the DST password are about the same as

that

of a

snowball inside a blast furnace, not gonna happen.

Use Larry's suggestion and from the console, signed on as

QSECOFR,

issue

the
CHGDSTPWD *DEFAULT command.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 4/12/2012 7:31 AM, Roberto José Etcheverry Romero wrote:

If you have 22222222 access you could SEE which disk is the
loadsource, just go to the rackconfig and it will be marked

with *

From there, take the serial number and just take each disk.

To aid in your hacking, stop all parity protection (one less

abstraction

layer).

And good luck i doubt the users/pass are stored in plaintext.
You could also dump an op21 and look at the lic code part...

Keep us posted, i'm curious about this.

best regards,

Roberto

On Thu, Apr 12, 2012 at 8:12 AM, DrFranken<

midrange@xxxxxxxxxxxx>

wrote:

Well I can tell you it's the top cage, left disk unit,

ALMOST

certainly.

It's possible that it's the 2nd disk from the left.

Now on this quest to find the DST Password with a disk
editor...... Yeah good luck with that.

I believe they are encrypted, and worse in EBCDIC so

noodling

for

recognizable stuff will be hard.

Why don't you run CHGDSTPWD and reset the QSECOFR DST

profile

that

way?

- Larry "DrFranken" Bolhuis

On 4/12/2012 6:44 AM, Jim Donoghue wrote:

I have this old 9406-720. It has five drives in the cage

on

the

top left side (below the control panel), and two in the

cage

below it. How do I find out which is the load source? I can

only

access DST with the '22222222'

user ID. I need to find the load source device so I can

poke

into it with a disk editor and hopefully find where the DST

passwords are stored.

Thanks,

Jim

--

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)

mailing list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please

take a

moment to review the archives at

http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)

mailing list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)

mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.