Jump to content

Issue with env variables


Recommended Posts

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,


Link to comment
Share on other sites

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}"

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 🙂


Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • lartsch changed the title to Issue with env variables


This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...