Hi, I'm your support robot today, thank you for shoping with lgogdownloader Softworks and leaving us so much money. And since every paying customer has a 25h+ support hotline, I'm here to help you :D [/sarcasm]

well I don't really understand the problem I think. if there's some way to enter your "osition-based interactively generated password" on the commandline as an argument, it should also far from impossible the do the same a two seconds after starting lgogdownloader, right?

And it's not like you have to enter it each time but only once and when you login succesfully once you get a cookie which lets you use lgogdownloader henceforth without a need for a password, which is pretty comfy and makes the "lgogdownloader --login $user $pass " commandline argument needless anyway.

Anyway, to be at least a bit helpful:
there's a tool called expect that you can install with you systems packet manager and then execute in a script like this: and it's taking over the login for you.
also note that you might have to login via browser once and save a cookie as cookie.txt if there's a captcha to solve from gog. but lgogdownloader will tell you what to do.

-Edit lol double ninja'd ... I'm getting slow
-Edit2: wow, I'm not only slow but also inattentive it seems. I only now realized by rereading your first post, that you already know about "expect". Hope it still helps, the little script worked (tested it) and it's not really witchcraft but pretty straightforward, although immi101 is of course right when he says it's quite the security risk to have your passwords lying around in plaintext files. So maybe in the end it's best to just enter the password this one time by hand ;)

It is! You promised to deliver! I demand my paycheck back! :D

I love sarcastic robots!

Seriously, thanks for pinging back, guys! Now down to the problem.


Well, you know that home is 600, bash_history is line-limited and a shell is also a program, so entering password into the shell is as dangerous as entering it into any unpriviledged the program.
Besides, shell is for scripting, and scripting relies on command line arguments, variables and exit codes to make amazing stuff, thus a CLI interface binary without support of all that is pretty much unusable for scripting as a back-end.


and that is a security risk. :)

anyways, entering position-based interactively generated password is very easy if: a) the entered characters are displayed in any form AND b) its possible to walk among them with arrow- and home/end keys, even blindly.

Unfortunately Lgogdownloader demands own login promt and does not display anything at all, so its pretty much usable only for linear-based static passwords, which are easier to enter, but they are more vulnerable and harder to update.

The big problem with expect is its really a witchcraft to use and a new science for me.
I already found out how to integrate it into the bash script, however there are few distrurbing things:
- I am totally new to it and would like to skip it if possible right now (don't want to learn another script language within a script language)
- so far as I understand it, its pretty static at "expect"ations. For example, one can only "expect" success text string, but can't detect and report failures.
- I have no idea how to make expect actually return all the strings the program wrote to stdout, so I can at least grep for the status. Basically, what a good program does with exit codes - I have to achieve via "expect" wheelchair, and can't manage.

So in the end, I have either to
1) call lgogdownloader --login in the terminal window (not the best esthetics and, again, it supports only linear passwords),

2) learn "expect" syntax and caveats so I can "wheelchair" that promt. If somebody can help me with that, that would be awesome.

3) Or should I download lgogdownloader source, autopatch the whole "security" thing out of C source and autocompile it; just to defeat the lgogdownloader's zen of login. :O

Gogrepo, on the other hand, fully supports invoke of $login $pass, but I'd like to cover the lgogdownloader as backend too.

I think it's actually 700 but thats just nitpicky... but a neat trick for having secrets in scripts that can be run but not read by others is straight from the expect man page:

Create the Expect script (that contains the secret data) as usual. Make its permissions be 750
(-rwxr-x---) and owned by a trusted group, i.e., a group which is allowed to read it. If neces‐
sary, create a new group for this purpose. Next, create a /bin/sh script with permissions 2751
(-rwxr-s--x) owned by the same group as before.

The result is a script which may be executed (and read) by anyone. When invoked, it runs the
Expect script.

sorry, I don't understand. on a shell lgogdownloader displays as much as any other command line tool does. How come it's easier to enter your password on the cli than on the lgogdownloader prompt?
Are you running it in a headless docker container?

(Also what kind of password are we talking here? I don't know what you mean by linear password vs. your location based thingie? gog still needs to have your password to authenticate you, so it can't be that different from the usual passwords all of us use. *just curious*)

And can you please also explain, why you can't just login via shell once, get your cookie and then backend script away with lgogdownloader since you won't be asked again for a password after that.?

actually I think it can detect and report failures but since I haven't known expect before your question, I am not deep enough into it to explain anything. But there should be plenty of example scripts floating around

As for getting everything from stdout that's what I used the interact command at the end of my example expect scrpt.
After that it just basically hands you back the shell and gives you all the output and input. (so expect only entered the credentials you gave it in the script in my last post and then gave you back control. the output is exactly the same as if you did it by hand)

I think Lin545 is complaining about lgogdownloader not using something like libreadline to allow you to make your password more difficult for primitive keyloggers to capture by typing "password" as "swo<Home>pas<End>rd".

The evil of sticky bit and storing of plain secret data in a plain text executable. But its not what I am doing. I am getting the data from GUI dialog and feeding it into the downloader backend, just like what scripts are for - to glue things.

No, lgogdownloader does not display anything when entering passwords.
The position-based password is dynamically generated.
For example:

your nickname is: mchack
your favorite food, which you can substitute - mutating whole password group as needed - is(for example): pizza
and you was born on day number(for example): 21
the gog full domain is: gog.com
the filler, if data is missing is a: "jf"

Password generation rule:
enter 6 letters of the domain, backwards:: moc.go
enter the day you were born as first and last symbols:: 2moc.go1
enter your nickname, one letter then skip a charater, next letter. But when entering, the first two symbols of your nickname are CAPITALS, second symbols as regulars, repeating: 2MmCohca.CgKo1
salt the example with your favorite food, backwards: 2MmCohca.CagzKzoi1p

this is an example position-based interactively generated password.
It has pros and cons to static linear password, but mostly its pros. The only substantial con is that it requires time to generate(enter). What static or dynamic data is involved in generation and algorythm - are all different and can be anything.

Because lgogdownloader does not display anything and does not support positional buttons, entering (reconstructing) such password is impossible.

This is the least feasable but possible option. It breaks consistency and as said, its only possible to enter linear passwords. I bet I will have to do this, but then I will write the function in script which either downloads, patches and builds lgogdownloader from source, adding argc/argv functionality; or if I conquer the "expect" wheelchair magic.

Well, basically you tell me that its sourcery for you too :)
I of course tried few scripts over internet, but none showed how can I get what program tries to stdin before quitting. I tried assinging expect call to the variable, but it cuts output right after password - even if password gets accepted.

Currently I am doing this in the script:

expect <<- EOD
spawn "$lgogfile" --login
expect "Email:*"
send -- "$kgogruntime_login\r"
expect "Password:*"
send -- "$kgogruntime_pass\r"
send -- "\r"
expect eof
EOD

And it works. But its blind and I can't detect such strings as:
"HTTP: Login successful"
"API: Login successful"
"Saving config: * /.config/lgogdownloader/config.cfg"

Btw, I managed to get localisation in scripts, without using additional files or po-files. I'll share it once I get it doing job at least half done.
Hey Stephan! Almost, I am actually entering passwords like libreadline myself. :)

Thanks for explaining :D but I somehow feel very much reminded of the good old xkcd.com/936 - (Password strength), I still remember to this day the correct horse battery staple ;) (and it's easy to input aswell...)

But I'm not here, to talk you into doing things differently, I'm earnestly sorry, if I sound that way, since I really hate those guys that instead of answering the question, tell you to change all the things leading to the question.
I was really curious on what you meant by your positional password scheme and you explained very well thanks.
Alas I'm afraid I can't help you.

As for your script, you might really wanna try out that interact command after your send -- "$kgogruntime_pass\r" line in that script. I'm pretty sure it'll give you all the stdout/-in you want.

From your description of how you generate a password, it sounds like we're talking about the same thing. (My "not using something like libreadline" looks like it means the same thing as your "does not support positional buttons")

I was just coming at the problem more from a programmer's perspective.

That XKCD picture... it depends. If attacker expects alphanummeric letters, its as easy hackable as a shorter smashing-monkey style. The idea of dynamically generated password is four-fold:
- it makes is much harder to keylog (since keypresses are irrelevant, mouse can be used for positioning too),
- it allows generation of very long and complex passwords which are very easy to reproduce,
- passwords are usually glued to resource data, can be login, parts of profile, or specifics from website. means each password will be unique,
- the passwords themselves are easily mass refreshable. For example, just changing favorite food, changes all passwords.

In comparsion to regular linear password, with a dyn-generated the owner does not keep the password in head - he keeps algorythm in head. Algorythm is the password.

The downside of the method is the entering speed, since it requires to be reconstructed live.
Its also bad for stuff which one is *supposed* to be shared with a group.

I am the author of this method btw, so feel free to criticize it :)

You already helped me a lot, thank you!

I am not good at python.. I have seen lgogd_uri source code, but I wasn't able to figure out how you send it the credentials. I am basically writing some basic GUI to it in a free time just for fun.

It relies on the user to run `lgogdownloader --login` in a terminal to acquire a login cookie.

Given that I've been using the same login cookie and ancient v2.25 copy of lgogdownloader for ages, I thought it was too much bother to provide a UI for logging in when I could simply copy-paste my long, hard-random password from my password manager to the terminal.

(I've been loathe to upgrade to current lgogdownloader because I'm running Kubuntu 14.04 LTS and, when I tried to install it on my brother's Kubuntu 14.04 LTS, it was crash-happy.)

I see. Thank you! I'll try to fun around with "expect magic" then :)

look around under /proc
lots of stuff there that is world-readable. Including the cmdline of running processes.
Given that and the fact that linux is designed as a multiuser system, it is generally considered "bad form" to use command line arguments to pass sensitive data.

I think what are you trying to tell is that proc arguments are world-readable via ps?
This is interesting! I think a proper way to do things is then pass them via config file. Like run the software for 1st time - it generates config. I can then write the pass/login into config and run the software, and it checks and throws exit code or text depending on outcome. Thanks!

Unfortunately, lgogdownloader does not support this empty config generation either. But I will check more.

yes, you can view any process' arguments by using 'ps'
or look them up yourself under:
cat /proc/<pid>/cmdline

As others have pointed out passing login information via command line is a security risk.

It should be easy to add an option to pass email and password via command line argument so I might add it as an option with big warning text to not use it unless you know what you're doing.

I'm currently messing with Galaxy API and thus my local repository is a big pile of hacked together code with some of the current login code rewritten.
It needs some major code cleanup before I'm going to commit it and move on to other stuff that even remotely touches the login code.