Issue with env variables

[lartsch]

Hey all,

I have the problem that some environment variables are not set on boot, like DUCKY_LANG, creating  issues with payloads. Mainly, my characters are not injected correctly with Q STRING.

I have checked the parser logs and the language file is correctly loaded on boot. Also, key recording and Q KEYCODE works as intended.

So I have looked into the QUACK script and found that the language setting is obtained with os.getenv("DUCKY_LANG", default="us"). I checked, and the variable is empty after boot so it defaults to US layout, explaining the problems I experience. I then noticed that other environment variables are also not set, for example TARGET_IP after going to an ethernet attack mode.

Please help me with this issue. 

Thanks and best regards,

lartsch

[lartsch]

Well, while this still poses an issue, I fixed it for me in terms of DUCKY_LANG at least, by adding this to the config parser in croc_framework:

      if [[ "$line" == DUCKY_LANG* ]]; then
          export DUCKY_LANG="$(echo "$line"| cut -d ' ' -f2- | awk '{print tolower($0)}')"
          sed -i "/export DUCKY_LANG/d" /root/.profile
          echo "export DUCKY_LANG=${DUCKY_LANG}" >> /root/.profile
                croclog "LANGUAGE DETECTED ${DUCKY_LANG}"
          continue
      fi

This will export the variable to all interactive shell sessions (through /root/.profile) and also make it available to all payloads. Works fine this way, but other environment variables are still not set, like TARGET_IP.

 

// edit: plus see my other comment. these fixes are QUICK AND DIRTY, keep that in mind - if you find a better way, please tell here 🙂

 

[chrizree]

I have experienced the same regarding DUCKY_LANG and did the same conclusion as you did when looking at the QUACK script. I did a more "quick and dirty" solution for it though, but I will use your suggestion in the future. I hope there will be updates to the Croc firmware soon. As I understand it, work is being made but I don't know anything about it or what the end result will be. It has been a while since I really used the Croc and I haven't experienced the TARGET_IP issue, so not sure what can be the root cause of that.

[lartsch]

Hey chrizree,

thanks for your reply. Good to know someone else is facing the problem.

In terms of ethernet mode related variables like TARGET_IP, TARGET_OS etc. I noticed the following:

• Match based payloads are run from /usr/local/croc/croc.py - for each payload run, a subprocess is started and /usr/local/croc/bin/GET as well as /usr/local/croc/bin/GET_VARS are each sourced for this subprocess. Therefore, for match based payloads, using (for ex.) GET TARGET_IP in the payload would work after going in ethernet attack mode.
• They don't work for MATCHLESS payloads, since those are run from /usr/local/croc/bin/croc_framework on boot. And in this implementation, no files are sourced so matchless payloads don't have access to GET [var]. 

I am a little bugged out about the issues with the framework/firmware at this point. It's such a capable tool but for its price I think one could expect a little higher quality in terms of software. A repository where we could do pull request would also be a benefit, both for hak5 and the community.

[lartsch]

Okay, I fixed the ethernet related env vars by adding this to the execute_non_match_payloads in croc_framework:

  source /usr/local/croc/bin/GET
  export -f GET

Without only source it did not work, so the extra export

// Edit: by the way, setting / sourcing DUCKY_LANG and GET in every (matchless) payload directly would also work, but to me this is something that should work automatically, therefore the fix