• Re: XPsp3 - (how to) retrieve OE6 newsgroup account name and password

    From Shadow@21:1/5 to All on Mon Feb 5 08:07:08 2024
    XPost: comp.os.ms-windows.programmer.win32

    On Mon, 5 Feb 2024 11:16:21 +0100, "R.Wieser" <address@is.invalid>
    wrote:

    Hello all,

    I'm still using OE6 to read/write newsgroup messages, and have written a >small program which retrieves the message count for each subscribed >newsgroup, so I can easily see if new messages are available for them.

    The thing is, at some point I need to provide a username and password. The >OE6 account already has them, but can't seem to be able to retrieve them for >my "new messages" checking program.

    Any idea where-and-how I can retrieve them ?

    I've already taken a peek at the 'CredRead' and family functions >(advapi32.ddl), but those return nothing. Presumably OE6 uses another >method.

    Nirsoft probably has an utility to retrieve them. Filemon or
    Regmon it and see where it searches.
    Don't have OE installed, so can't test it myself.
    []'s
    --
    Don't be evil - Google 2004
    We have a new policy - Google 2012
    Google Fuchsia - 2021

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Mon Feb 5 11:16:21 2024
    XPost: comp.os.ms-windows.programmer.win32

    Hello all,

    I'm still using OE6 to read/write newsgroup messages, and have written a
    small program which retrieves the message count for each subscribed
    newsgroup, so I can easily see if new messages are available for them.

    The thing is, at some point I need to provide a username and password. The
    OE6 account already has them, but can't seem to be able to retrieve them for
    my "new messages" checking program.

    Any idea where-and-how I can retrieve them ?

    I've already taken a peek at the 'CredRead' and family functions (advapi32.ddl), but those return nothing. Presumably OE6 uses another
    method.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Mon Feb 5 13:03:35 2024
    XPost: comp.os.ms-windows.programmer.win32

    Shadow,

    The thing is, at some point I need to provide a username and password.
    The OE6 account already has them, but can't seem to be able to retrieve >>them for my "new messages" checking program.

    Any idea where-and-how I can retrieve them ?
    ...
    Nirsoft probably has an utility to retrieve them. Filemon or
    Regmon it and see where it searches.

    Ah, I see that I should have been a bit clearer.

    I have both the needed username and password, and currently have them
    hardcoded in my "new messages" program. But that means that when I
    add/change an account I need to edit the program by hand. And as I'm lazy
    (as all programmers are :-) ) I would like to skip that step, and have the program retrieve that information by itself.


    After posting my question I did some "googeling", and found that the account data gets stored in the registry here :

    HKEY_CURRENT_USER\Software\Microsoft\Internet Account Manager\Accounts

    It holds all kinds of stuff, but the accounts password is not among them. Although there is a "NNTP Password2" key present, its data doesn't live up
    to it.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From JJ@21:1/5 to R.Wieser on Mon Feb 5 20:54:50 2024
    XPost: comp.os.ms-windows.programmer.win32

    On Mon, 5 Feb 2024 13:03:35 +0100, R.Wieser wrote:

    Although there is a "NNTP Password2" key present, its data doesn't live up
    to it.

    What do you mean? It's there in plain sight. Unencrypted and unobfuscated.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Mon Feb 5 15:35:11 2024
    XPost: comp.os.ms-windows.programmer.win32

    JJ,

    Although there is a "NNTP Password2" key present, its data doesn't live
    up
    to it.

    What do you mean? It's there in plain sight. Unencrypted and unobfuscated.

    When I compare the keys data with the actual password (the first thing I
    did, duh) they do not match. At all.

    The keys data starts with 0x01,0x02. My password as all ASCII.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From VanguardLH@21:1/5 to R.Wieser on Mon Feb 5 11:17:23 2024
    XPost: comp.os.ms-windows.programmer.win32

    "R.Wieser" <address@is.invalid> wrote:

    I'm still using OE6 to read/write newsgroup messages, and have written
    a small program which retrieves the message count for each subscribed newsgroup, so I can easily see if new messages are available for
    them.

    The thing is, at some point I need to provide a username and
    password. The OE6 account already has them, but can't seem to be
    able to retrieve them for my "new messages" checking program.

    Any idea where-and-how I can retrieve them ?

    I've already taken a peek at the 'CredRead' and family functions (advapi32.ddl), but those return nothing. Presumably OE6 uses
    another method.

    https://www.nucleustechnologies.com/blog/know-your-outlook-password-location/

    Not even those with admin privileges for their Windows account can see
    the hidden crypto hive in the registry. regedit.exe doesn't show
    everything.

    As I recall, Pstore got deprecated (replaced with Data Protection API;
    see https://en.wikipedia.org/wiki/Data_Protection_API), and made
    read-only in Windows Vista, so programs could find their old login
    credentials in Pstore, but you couldn't change them. That meant some
    programs still using Pstore couldn't store their credentials as of
    Windows Vista.

    https://en.wikipedia.org/wiki/List_of_features_removed_in_Windows_Vista
    Protected Storage (PStore) has been deprecated and therefore made
    read-only in Windows Vista. Microsoft recommends using DPAPI to add
    new PStore data items or manage existing ones.[35] However existing
    applications such as Outlook 2002 which used PStore are unable to save
    passwords as a result. Any application that tries to create new PStore
    data items will fail."

    You're still back on Windows XP, so Pstore (pstore.exe) is still used
    there. I've never had to delve into Pstore, and it's way too late for
    me to start now. OE would have the hints needed to extract its
    credentials from Pstore along with code to provide the hints of what
    items to extract. You can start learning about Pstore here:

    https://learn.microsoft.com/en-us/windows/win32/devnotes/pstore
    (Considering this is only for Windows XP and Server 2003, I'm surprised Microsoft hasn't taken down this web page since they remove lots of docs
    for old Windows versions when they get discontinued.)

    I've not looked into getting a list of Pstore providers used to access protected data in Pstore. The article above has a sub-article on how to
    code to get a list of those. Pstore corruption is one of the causes for
    OE to be very slow; see:

    https://support.microsoft.com/en-au/topic/olexp-outlook-express-performance-is-slow-a5548db3-b7e0-689a-475b-91c535dbefc6

    However, the step suggesting to delete the ProtectedStorage registry key
    means losing all credentials stored there for any program using Pstore.
    I'm surprised even back in Windows XP that the key wasn't protected with
    access privileges that you had to change, like take Ownership, apply,
    and then change/add users with full control privileges. Maybe the
    registry wasn't so well protected back in Windows XP from user mistakes.
    I'm not sure if any non-Microsoft programs (and any other than Outlook
    98 and OE) used Pstore. DPAPI was available back in Windows 2000, so it overlap and superseded Pstore.

    OE supported plug-ins; for examples, see:

    https://www.mapilab.com/outlook_express/

    At one time for a short time, Microsoft provided documentation on OE
    plug-ins, but they yanked it, because they considered it too flaky.

    https://en.wikipedia.org/wiki/Outlook_Express#Extensibility

    I don't know if anyone grabbed the doc, and I don't know the URL to see
    if web.archive.org has an old page with the doc. Possibly a script
    could ask a plug-in to ask OE to get the login credentials to put in a
    temp file that a script could read, and then destroy the file (not just
    delete, but erase its sectors). Looks some devs came up with their own
    API to write add-ins for OE, like:

    https://www.add-in-express.com/programming-outlook-express/

    Rather than delve into all that trying to gain expertise in something
    that is dead, why not hard code the login credentials into your script?
    Yeah, you end up exposing the login credentials in what is likely text
    to define a script, so you might need to figure out how to do something
    of reduced Pstore functionality by encrypting the login credentials into
    a file, and somehow obfuscating your decrypt key(s).

    While Nirsoft has some tools to get at protected data (see https://www.nirsoft.net/password_recovery_tools.html), some only work
    wit DPAPI. His Protected Storage PassView tool (pspv.exe) looks for
    passwords stored in Pstore. I have some of his tools, but didn't keep
    this one since Pstore died with Windows XP/Server 2003.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Mon Feb 5 19:31:14 2024
    XPost: comp.os.ms-windows.programmer.win32

    Vanguard,

    Thank you for the links and explanation to them.

    Further googeling (following some hunches) resulted in finding the registry
    key to where the OutLook Express accounts is stored. Although the name is
    there the password isn't stored there.

    Not even those with admin privileges for their Windows account
    can see the hidden crypto hive in the registry.

    I'm going to assume that the crypto hive is protected by the OS, meaning
    that low-level access to the registry thru NTDLL won't help either.

    replaced with Data Protection API;
    see https://en.wikipedia.org/wiki/Data_Protection_API

    Alas, that page talks a lot, but doesn't tell me anything. After having
    read it I do not even know which (XPsp3) DLLs are involved :-|


    The problem with all I find is that I've still got zero in regard to information (sample code) to what to use and how to apply it.

    https://learn.microsoft.com/en-us/windows/win32/devnotes/pstore

    The problem with MS is that, contradicting the domans name, that site works well enough when you know what to do but need to check how to call the functions, but not all that much when you are trying to figure out what you need do to arrive at a goal. :-(

    I could try and and see what all those enums return, but I would be
    stumbling in the dark. Probably will try anyway though, its the best thing
    I currently got (not that hard when you got nothing :-) ).

    I don't think I will mess up the store in any way, as all I need is read access.

    As for the possibility to write some plug-ins for OE ? I am not trying to extend OE - how would I access the results from another program ?

    why not hard code the login credentials into your script? Yeah, you
    end up exposing the login credentials

    Thats currently what I'm doing, and not all worried about exposing them.

    The thing is the above solution means that I have to manage the data
    (username, password) at (several) different places, and would like to bring that back to just a single one.

    Having to deal with encryption (thru pstore or other) is how it was
    implemented in Outlook Express, and I have no other choice(?) than to do the same.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From VanguardLH@21:1/5 to R.Wieser on Mon Feb 5 17:10:03 2024
    XPost: comp.os.ms-windows.programmer.win32

    "R.Wieser" <address@is.invalid> wrote:

    Vanguard,

    Thank you for the links and explanation to them.

    Further googeling (following some hunches) resulted in finding the registry key to where the OutLook Express accounts is stored. Although the name is there the password isn't stored there.

    Not even those with admin privileges for their Windows account
    can see the hidden crypto hive in the registry.

    I'm going to assume that the crypto hive is protected by the OS, meaning
    that low-level access to the registry thru NTDLL won't help either.

    replaced with Data Protection API;
    see https://en.wikipedia.org/wiki/Data_Protection_API

    Alas, that page talks a lot, but doesn't tell me anything. After having
    read it I do not even know which (XPsp3) DLLs are involved :-|

    The problem with all I find is that I've still got zero in regard to information (sample code) to what to use and how to apply it.

    https://learn.microsoft.com/en-us/windows/win32/devnotes/pstore

    The problem with MS is that, contradicting the domans name, that site works well enough when you know what to do but need to check how to call the functions, but not all that much when you are trying to figure out what you need do to arrive at a goal. :-(

    I could try and and see what all those enums return, but I would be
    stumbling in the dark. Probably will try anyway though, its the best thing I currently got (not that hard when you got nothing :-) ).

    I don't think I will mess up the store in any way, as all I need is read access.

    As for the possibility to write some plug-ins for OE ? I am not trying to extend OE - how would I access the results from another program ?

    why not hard code the login credentials into your script? Yeah, you
    end up exposing the login credentials

    Thats currently what I'm doing, and not all worried about exposing them.

    The thing is the above solution means that I have to manage the data (username, password) at (several) different places, and would like to bring that back to just a single one.

    Having to deal with encryption (thru pstore or other) is how it was implemented in Outlook Express, and I have no other choice(?) than to do the same.

    Regards,
    Rudy Wieser

    If you find the documentation on writing OE plug-ins, perhaps there was
    a function to ask OE for login credentials. OE gets the data from its
    Pstore data, and returns to the plug-in. Seem far fetched that plug-ins
    would have access to that info since that seems a security hole.

    Without the hints in OE itself on how it uses Pstore, and what key it
    used to seed the encryption, not sure you'll get it outside of OE.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Tue Feb 6 08:19:37 2024
    XPost: comp.os.ms-windows.programmer.win32

    Vanguard,

    If you find the documentation on writing OE plug-ins, perhaps there
    was a function to ask OE for login credentials. OE gets the data
    from its Pstore data, and returns to the plug-in.

    And than I would need to find a way to have another program communicate with such a plug-in, a way that is not given to exist.

    Seem far fetched that plug-ins would have access to that info since
    that seems a security hole.

    And then there is that ofcourse.

    Without the hints in OE itself on how it uses Pstore, and what
    key it used to seed the encryption, not sure you'll get it
    outside of OE.

    :-) Thats what this question is all about : if someone knows how to retrieve/extract the sought for data from OE6, sparing me (possible
    fruitless) hours-upon-hours scouring possible leads in the hope to find such
    a hint.

    I already checked what DLLs and functions thereof it exports, but none are geared towards encryption.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From VanguardLH@21:1/5 to R.Wieser on Tue Feb 6 14:57:46 2024
    XPost: comp.os.ms-windows.programmer.win32

    "R.Wieser" <address@is.invalid> wrote:

    Thats what this question is all about : if someone knows how to retrieve/extract the sought for data from OE6, sparing me (possible fruitless) hours-upon-hours scouring possible leads in the hope to find such a hint.

    Seems way too much works for just one instance of OE, so my guess is you
    use your script on many instances of OE.

    If all you need is the password(s) from OE from one instance, why not
    use Nirsoft's Protected Storage Passview (pspv) tool already mentioned (https://www.nirsoft.net/utils/pspv.html)? It has command-line
    arguments to save the passwords into a file. Your script could call it
    via command-line, and then your script would parse the output file to
    find the OE passwords. I don't what its output file looks like
    regarding syntax to know if there are separate sections for each type of
    app that uses Pstore, or if all passwords in Pstore get dumped out en
    masse without any indicator of the app to which they belong. Since I'm
    on Windows 10, there is no Pstore there to dump anything out of it.
    You'd have to see what pspv showed you.

    From the GUI version of pspv, there is a column called "Resource Type",
    and the example shows "Outlook Express" as one of those. So, perhaps
    the command-line arg to output to a file will also show Resource Types.
    My guess is the output will be records (lines) with fields, and one of
    the fields would be the resource type.

    I'd watch pspv to see if it was issuring pstore.exe commands. If so,
    you could see the syntax of those commands to use in your script. Else,
    you could contact Nir Sofer (nirsofer@yahoo.com) to see if he was
    conducive to showing you his source code for pspv.

    Note that Pstore is only used if the user selects to save the password
    when they access an account using OE. If the user elects to manually
    enter it each time, the password does not get saved in Pstore.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Wed Feb 7 07:42:26 2024
    XPost: comp.os.ms-windows.programmer.win32

    Vanguard,

    Thats what this question is all about : if someone knows how to
    retrieve/extract the sought for data from OE6, sparing me (possible
    fruitless) hours-upon-hours scouring possible leads in the hope to find
    such
    a hint.

    Seems way too much works for just one instance of OE,

    Indeed*, hence my question. An example of what needs to be done and how
    would fix.

    * though I'm a hobby programmer, and just/might/ go thru all that trouble
    just to see if I can actually do it. You know, like some people like to put
    a 10.000 piece puzzle together.

    so my guess is you use your script on many instances of OE.

    Nope. Just one.

    And what "your script" are you talking about ?

    why not use Nirsoft's Protected Storage Passview (pspv) tool already mentioned (https://www.nirsoft.net/utils/pspv.html)?

    Reasons:

    1) Knowledge. I like to know how its done.

    2) Interoperability. it won't work well together with my program (which is
    GUI based)

    3) Having a hobby. I dislike using other peoples (small) programs when I can write them myself (also see #1).

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Wed Feb 7 09:32:48 2024
    XPost: comp.os.ms-windows.programmer.win32

    Vanguard,

    https://learn.microsoft.com/en-us/windows/win32/devnotes/pstore

    The problem with MS is that, contradicting the domans name, that site
    works well enough when you know what to do but need to check how to call
    the functions, but not all that much when you are trying to figure out
    what you need do to arrive at a goal. :-(

    To make a point :

    I just enumerated the "PStoreProviders" using IEnumPStoreProviders::Next",
    but am now looking at ... I have no idea, and MS webpage about it* doesn't explain it either.

    * https://learn.microsoft.com/en-us/windows/win32/devnotes/ienumpstoreproviders-next

    Worse, the "[out] LPWSTR *rgelt" argument is described as :

    "A pointer to a string in which to return the provider type name."

    As its an "LPWSTR" I'm /assuming/ it returns a pointer to a string manages
    it itself. But the phrasing "A pointer to a string in which to return"
    seems to indicate I have to provide space for such a string myself.

    To check I just provided a pointer to some space and compared that with what got returned, and they differ. Which seems to indicate my first hunch was correct, and the "A pointer to a string in which to return" *should* have
    been written as "in which a pointer to a string is returned".

    ... which still is wrong, as it looks like some /value/ is returned (the
    first four bytes are 0x1C 0x00 0x00 0x00. Not at all looking like a string, wide or not).

    Ofcourse, with the MS webpages giving zero indication to what that code
    might mean.


    Second, very similar issue : I thought I could take a look at what "IEnumPStoreItems::next" would return (and get lucky and get the password).
    For that I need to call the "IPStore"s "EnumItems" method. But although MS provided a list of methods*, there is no indication of if that list is in VTable order. As such I can't even create the needed VTable.

    * https://learn.microsoft.com/en-us/windows/win32/devnotes/ipstore


    And than there is the problem that that "EnumItems" method needs "pItemType" and "pItemSubtype" arguments, which are not described anywhere either. And without them I don't stand a chance of even getting the enumeration started. :-(


    IOW, even when I go to the horses mouth to get my information I do not get everything thats needed (and have to scour the internet to hopefully find
    it).

    And by the way : I've not seen the msimn.exe or msoe.dll import the
    pstore.dll anywhere.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Shadow@21:1/5 to All on Wed Feb 7 09:57:12 2024
    On Wed, 7 Feb 2024 07:42:26 +0100, "R.Wieser" <address@is.invalid>
    wrote:

    Vanguard,

    Thats what this question is all about : if someone knows how to
    retrieve/extract the sought for data from OE6, sparing me (possible
    fruitless) hours-upon-hours scouring possible leads in the hope to find
    such
    a hint.

    Seems way too much works for just one instance of OE,

    Indeed*, hence my question. An example of what needs to be done and how >would fix.

    * though I'm a hobby programmer, and just/might/ go thru all that trouble >just to see if I can actually do it. You know, like some people like to put >a 10.000 piece puzzle together.

    so my guess is you use your script on many instances of OE.

    Nope. Just one.

    And what "your script" are you talking about ?

    why not use Nirsoft's Protected Storage Passview (pspv) tool already
    mentioned (https://www.nirsoft.net/utils/pspv.html)?

    Reasons:

    1) Knowledge. I like to know how its done.

    Use OllyDbg2 or x64dbg and trace the program, so you can see
    what files (or registry keys) it opens, what APIs it calls and even
    step through whatever horrible code routines it runs. You can adapt
    that to your program.
    I don't think Nir apps use any protection.

    Both debuggers are free, though Olly is somewhat outdated.

    I recommend

    <https://sourceforge.net/projects/x64dbg/files/snapshots/>

    Runs fine under XP SP3.
    []'s

    2) Interoperability. it won't work well together with my program (which is >GUI based)

    3) Having a hobby. I dislike using other peoples (small) programs when I can >write them myself (also see #1).

    Regards,
    Rudy Wieser

    --
    Don't be evil - Google 2004
    We have a new policy - Google 2012
    Google Fuchsia - 2021

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Wed Feb 7 14:54:42 2024
    Shadow,

    Use OllyDbg2 or x64dbg and trace the program, so you can see
    what files (or registry keys) it opens, what APIs it calls and even
    step through whatever horrible code routines it runs. You can adapt
    that to your program.
    I don't think Nir apps use any protection.

    Both debuggers are free, though Olly is somewhat outdated.

    I recommend

    <https://sourceforge.net/projects/x64dbg/files/snapshots/>

    Thanks for the suggestion, but have not used a debugger since .. well,
    forever (don't like them).

    Though over time I've found and created a few programs which could aid me in drilling down to the matter*. It only would take, just as with going thru
    it with a debugger following hunces, time to work thru all the
    possibilities - especially when its not known what method OE6 uses to store
    the password.

    * IDA, snapshotters showing loaded DLLs. The possibility to intercept DLL calls and log what goes in and comes out. Same for COM objects (like
    pstore).

    But as said, (this time) I would like to forgo that lengthy process, and
    rely on what others have (almost with no doubt) already done before.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Shadow@21:1/5 to All on Wed Feb 7 13:04:18 2024
    On Wed, 7 Feb 2024 14:54:42 +0100, "R.Wieser" <address@is.invalid>
    wrote:

    Shadow,

    Use OllyDbg2 or x64dbg and trace the program, so you can see
    what files (or registry keys) it opens, what APIs it calls and even
    step through whatever horrible code routines it runs. You can adapt
    that to your program.
    I don't think Nir apps use any protection.

    Both debuggers are free, though Olly is somewhat outdated.

    I recommend

    <https://sourceforge.net/projects/x64dbg/files/snapshots/>

    Thanks for the suggestion, but have not used a debugger since .. well, >forever (don't like them).

    Well, I love them. One of the reasons I still use XP.

    Linux's debuggers are either not intuitive or incomplete (edb-debugger).

    x64dbg has a very shallow learning curve and is portable,
    nothing gets installed. Most of the options are on menus, and the
    standard keys (F2=break here, F7=step into a call, F8=step over a
    call, and F9 = run to the end of the program) are the same as OllyDbg.

    Whatever, your choice.
    []'s
    Though over time I've found and created a few programs which could aid me in >drilling down to the matter*. It only would take, just as with going thru
    it with a debugger following hunces, time to work thru all the
    possibilities - especially when its not known what method OE6 uses to store >the password.

    * IDA, snapshotters showing loaded DLLs. The possibility to intercept DLL >calls and log what goes in and comes out. Same for COM objects (like
    pstore).

    But as said, (this time) I would like to forgo that lengthy process, and
    rely on what others have (almost with no doubt) already done before.

    Regards,
    Rudy Wieser

    --
    Don't be evil - Google 2004
    We have a new policy - Google 2012
    Google Fuchsia - 2021

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From VanguardLH@21:1/5 to R.Wieser on Wed Feb 7 12:49:46 2024
    XPost: comp.os.ms-windows.programmer.win32

    "R.Wieser" <address@is.invalid> wrote:

    And what "your script" are you talking about ?

    Reread your first message. Says you're using a program. Well that
    could be compiled C, or some other language, a script, or whatever that executes code whether compiled or intrepreted. Can your program call
    external programs, like to run pspv.exe with command-line args?

    why not use Nirsoft's Protected Storage Passview (pspv) tool already
    mentioned (https://www.nirsoft.net/utils/pspv.html)?

    3) Having a hobby. I dislike using other peoples (small) programs when
    I can write them myself (also see #1).

    Then I suggest writing to Nir Sofer to ask if he will show you his code;
    else, you're into learning Pstore programming. I only know about Pstore because of problems with OE back in XP many years ago. I never go into
    delving into Pstore nor using any code to extract data from it.
    Microsoft's articles describe what it is, and describes some functions
    (already gave the URL to the MS article, but really isn't where you go
    for programming guidance unless you really want to learn from the ground
    up by trial and error. Pstore was a Windows XP-only thing, became read
    only in Windows Vista, and dropped in Windows 7, so not sure if you'll
    find many hits in online search on Pstore programming.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Wed Feb 7 20:58:37 2024
    XPost: comp.os.ms-windows.programmer.win32

    Vanguard,

    And what "your script" are you talking about ?

    Reread your first message. Says you're using a program.

    Indeed, "a program". Not "a script".

    Well that could be compiled C, or some other language, a script,
    or whatever that executes code whether compiled or intrepreted.

    Again, indeed.

    But somehow you decided that my program must have been of the subtype
    "script". How come ?

    Can your program call external programs, like to run pspv.exe
    with command-line args?

    Nope, sorry.

    Then I suggest writing to Nir Sofer to ask if he will show you
    his code;

    :-) If he wanted to share it I would have already found his sourcecode. Outlook Express is over two decades old.

    Hmmm... that pspv.exe program is just 52 KByte. Perhaps I should pull it
    thru the disassembler and see what I can glean from it ..

    else, you're into learning Pstore programming.

    Yeah, about that : I just spend some time trying to "google" that IPStore objects vtable. I can find some partial Linux info, but nothing about the
    one in Windows. And without that VTable I don't know how to call a named method. And without being able to do that ...

    Pstore was a Windows XP-only thing, became read only in Windows
    Vista, and dropped in Windows 7

    Yep. Every webpage about its functions, methods, constants and types has
    that info directly below its title. Almost as if they wanted to make sure
    you could not miss it. :-)


    I would have thought that the information itself would, if not on an MS website, still be floating around somewhere. It looks like I was wrong in that.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From VanguardLH@21:1/5 to R.Wieser on Wed Feb 7 18:50:37 2024
    XPost: comp.os.ms-windows.programmer.win32

    "R.Wieser" <address@is.invalid> wrote:

    Vanguard,

    https://learn.microsoft.com/en-us/windows/win32/devnotes/pstore

    The problem with MS is that, contradicting the domans name, that site
    works well enough when you know what to do but need to check how to call
    the functions, but not all that much when you are trying to figure out
    what you need do to arrive at a goal. :-(

    To make a point :

    I just enumerated the "PStoreProviders" using IEnumPStoreProviders::Next", but am now looking at ... I have no idea, and MS webpage about it* doesn't explain it either.

    * https://learn.microsoft.com/en-us/windows/win32/devnotes/ienumpstoreproviders-next

    Worse, the "[out] LPWSTR *rgelt" argument is described as :

    "A pointer to a string in which to return the provider type name."

    As its an "LPWSTR" I'm /assuming/ it returns a pointer to a string manages
    it itself. But the phrasing "A pointer to a string in which to return"
    seems to indicate I have to provide space for such a string myself.

    To check I just provided a pointer to some space and compared that with what got returned, and they differ. Which seems to indicate my first hunch was correct, and the "A pointer to a string in which to return" *should* have been written as "in which a pointer to a string is returned".

    ... which still is wrong, as it looks like some /value/ is returned (the first four bytes are 0x1C 0x00 0x00 0x00. Not at all looking like a string, wide or not).

    Ofcourse, with the MS webpages giving zero indication to what that code
    might mean.

    Second, very similar issue : I thought I could take a look at what "IEnumPStoreItems::next" would return (and get lucky and get the password). For that I need to call the "IPStore"s "EnumItems" method. But although MS provided a list of methods*, there is no indication of if that list is in VTable order. As such I can't even create the needed VTable.

    * https://learn.microsoft.com/en-us/windows/win32/devnotes/ipstore

    And than there is the problem that that "EnumItems" method needs "pItemType" and "pItemSubtype" arguments, which are not described anywhere either. And without them I don't stand a chance of even getting the enumeration started. :-(

    IOW, even when I go to the horses mouth to get my information I do not get everything thats needed (and have to scour the internet to hopefully find it).

    And by the way : I've not seen the msimn.exe or msoe.dll import the pstore.dll anywhere.

    Before going off on a red herring, have you used Nirsoft PSPV to check
    if there is anything in Pstore (for the Windows account under which you
    are logged into since Pstore is a per-user crypto cache)? Along with
    its Resource Type column that should show 1, or more, entries named
    "Outlook Express", it should also show non-blank username and password credentials. If PSPV doesn't list any Pstore entries, somehow OE is
    saving the login credentials elsewhere. Everything I read, and for
    resolution of some problems with account logins in OE, Pstore was used
    by OE to store login credentials. If PSPV doesn't show any login creds
    for OE, there's nothing there to pull out.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From VanguardLH@21:1/5 to R.Wieser on Thu Feb 8 13:14:25 2024
    XPost: comp.os.ms-windows.programmer.win32

    "R.Wieser" <address@is.invalid> wrote:

    I just realized : as the pspv program is GUI (and not console) based, how
    did you think you could retrieve (get it to return) the password ?

    It has command-line args to dump to file. That's why I wondered if your program could call an external program to create the output file, and
    then your program would parse the output file to extract the OE creds.

    https://www.nirsoft.net/utils/pspv.html
    Scroll down to the "Command-line options" section.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Thu Feb 8 07:11:11 2024
    XPost: comp.os.ms-windows.programmer.win32

    Vanguard,

    Before going off on a red herring, have you used Nirsoft PSPV
    to check if there is anything in Pstore (...) ?

    You have a point, and I did not do so until just now. There are multiple "outlook express" entries. And yes, one with the (accountname, username
    and) password I am looking for.

    Though I already found out that pstorec.dll is used (and the pstore object created), it didn't tell me if something has been stored in it.

    (for the Windows account under which you are logged into since
    Pstore is a per-user crypto cache)?

    :-) It would not be much of a /protected/ store if the different users could just take a peek at each others (username and) passwords. IOW, I already assumed it would be linked to the users account.


    I just realized : as the pspv program is GUI (and not console) based, how
    did you think you could retrieve (get it to return) the password ?

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Thu Feb 8 20:46:56 2024
    XPost: comp.os.ms-windows.programmer.win32

    Vanguard (and others),

    Thats what this question is all about : if someone knows how to
    retrieve/extract the sought for data from OE6, sparing me (possible
    fruitless) hours-upon-hours scouring possible leads in the hope to find
    such
    a hint.

    Seems way too much works for just one instance of OE,

    I got lucky, and found the order of methods of the iPStore vtable in an incomplete PowerBasic snippet. That helped quite a bit. Combined with a few other incomplete snippets I was able to figure out what needed to be done to get a list of OE (mail and news) passwords (and some other stuff).

    Looking /back/ its not at all complex. When I was looking /forward/ however ...

    I stil have to go thru the OE accounts data in the registry to retrieve the data needed to select the correct password to extract, but that should not
    be a problem.

    Or, with /way/ less words : "mischief managed". :-)

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Fri Feb 9 09:40:59 2024
    XPost: comp.os.ms-windows.programmer.win32

    Vanguard,

    I just realized : as the pspv program is GUI (and not console) based, how
    did you think you could retrieve (get it to return) the password ?

    It has command-line args to dump to file.
    ...
    https://www.nirsoft.net/utils/pspv.html
    Scroll down to the "Command-line options" section.

    Thanks. I did not notice those before.

    That's why I wondered if your program could call an external program
    to create the output file, and then your program would parse the output
    file to extract the OE creds.

    My current program reads the username and password from an INI file. I
    could imagine a (VB)script running the psvp program, reading the output and stuffing the read items into the INI file, and than start my program.

    A bit of a downside : the psvp program does not seem to mark email and newsgroups differently (even though the registy "Accounts" entries make it rather clear which type they are - pop3/smtp vs nntp). The generated INI
    would be a bit murky ...

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From VanguardLH@21:1/5 to R.Wieser on Fri Feb 9 11:38:09 2024
    XPost: comp.os.ms-windows.programmer.win32

    "R.Wieser" <address@is.invalid> wrote:

    A bit of a downside : the psvp program does not seem to mark email and newsgroups differently (even though the registy "Accounts" entries
    make it rather clear which type they are - pop3/smtp vs nntp). The
    generated INI would be a bit murky ...

    Other than the Resource Type that identifies the credentials belong to
    Outlook Express, doesn't the Resource Name identify the account? I'm
    going by the Nirsoft PSPV sample shown at its web site. The column
    headers shown in PSPV are:

    Resource Name
    Resource Type
    User Name/Value
    Password

    The Resource Name looks to be the account name. It won't help if you
    give e-mail and newsgroups accounts the same name. However, I don't see
    the Resource Name, or another field shown, that identifies the type of
    account, just its name.

    If the registry entries identify type of account, and also give the
    account name, you could pair up the registry account name for NNTP
    accounts with the PSPV Resource Names. You'd have a table of registry
    account names of NNTP type, pair the account name to the PSPV Resource
    Name, and then get the password from the matching PSPV entry.

    Pstore was just to secrete the passwords (and usernames), and really
    that's all it did. Supposedly the program using Pstore would know which Resource Name to use for which account, but maybe it got that from the
    accounts list in the registry.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Fri Feb 9 20:31:26 2024
    XPost: comp.os.ms-windows.programmer.win32

    Vanguard,

    A bit of a downside : the psvp program does not seem to mark email
    andnewsgroups differently (even though the registy "Accounts"
    entries make it rather clear which type they are - pop3/smtp vs
    nntp). The generated INI would be a bit murky ...

    It won't help if you give e-mail and newsgroups accounts the same name.

    That.

    If the registry entries identify type of account, and also give the
    account name, you could pair up the registry account name for NNTP
    accounts with the PSPV Resource Names.

    Oh man, thats hacks and more hacks ...

    Yes, it could be done that way. No, there is not a single hair on my head which would think of creating such a "solution". Sorry.


    Luckily I have some finished pstore code, as well as most of the registry account-retrieval code. A bit more work tomorrow and I will have a nice function which I can feed a newsgroup-servers name and get its username and password back.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)