Jim -
If you have the time, perhaps you should document what you have done here In the Midrange Wiki for the community.
- sjl


"Jim Donoghue" wrote in message news:mailman.9944.1334285072.14575.midrange-l@xxxxxxxxxxxx...

Ok, now for an update:

I figured out the LRC code (easy) and put the function in to my disk
editor. Now I can patch sectors!

Then, I carefully examined the functional DST user ID 22222222, and the
QSECOFR that I can't access. I 'copied' the values in the privileges list
from QSECOFR to 22222222. Replaced the drive into the 720, crossed my
fingers, and powered it up.

No errors! I was able to log in as '22222222'. So far, so good. But did it
work?

Of course it did! I went to look at the DST user profiles, and where it
only used to show '22222222', it shows them all. Of course I changed the
QSECOFR password to something that would work.

Next step.. reset the operating system default password.... Works ok (at
least the screen says the password override is set)

IPL the system...wait...

And log in as QSECOFR with default password!

Now I am at a screen 'Work with PTFs' - I have never seen this before and
don't know what to do now.

BTW, this is V5R3

I've got some reading to do.

Jim


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

i havent used the wiki yet, but this is the kind of knowledge that
should go into that.
I cant be the only one that always wondered what was in those sectors.

Best regards,


On Thu, Apr 12, 2012 at 9:52 PM, Jim Donoghue <jdonoghue04@xxxxxxxxx>
wrote:
> Some more interesting information:
>
> The 522-byte sector contains the 8-byte header, 512 data bytes, and 2
bytes
> at the end. The 2 bytes at the end are a LRC code (checksum), but only
one
> byte is used (the low-order one).
>
> Jim
>
>
> On Thu, Apr 12, 2012 at 6:57 PM, Jim Donoghue <jdonoghue04@xxxxxxxxx>
wrote:
>
>> Thank you. This will be extremely helpful, I just need to find some >> good
>> '6713' drives.
>>
>> Jim
>>
>>
>>
>> On Thu, Apr 12, 2012 at 5:55 PM, DrFranken <midrange@xxxxxxxxxxxx>
wrote:
>>
>>> Well you can install another drive, format it if it shows DPHnnnn
(write
>>> protected), then use the copy disk unit data - not the copy load
source.
>>>
>>> Now you can power down, swap the LS and the new drive and come back >>> up.
>>>
>>> You will however have this issue: The new LS drive is not RAID
protected
>>> because the O/S copied it's DATA not it's SECTORS. So a better option
>>> would be:
>>>
>>> Install it
>>> Format. This is a good idea even if you don't need to.
>>> Include it in RAID. If you formatted it first this will be very fast.
If
>>> not it will format it.
>>> NOW copy disk unit data.
>>> Power down
>>> Swap the drives physically.
>>> Power back up. Possibly you'll be able to exclude that drive from
RAID
>>> and if you can then you can physically pull it out. If you cannot
>>> exclude it (because it has RAID strip data on it) then it will have to
>>> stay for now.
>>>
>>> If you attempt an 'out of the box' drive duplication it will fail to
IPL
>>> because the LIC absolutely cares about serial numbers. Every drive has
a
>>> copy of the list of drives in the ASP so it knows if they have all
>>> checked in.
>>>
>>> - Larry "DrFranken" Bolhuis
>>>
>>> On 4/12/2012 5:24 PM, Jim Donoghue 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.
>
--
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 thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].