MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » April 2012

Re: Load source on old 9406-720



fixed

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.






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact