RazerBlade Posted April 9, 2017 Share Posted April 9, 2017 Hello! I have run into a problem on the new 1.1 Firmware for the BashBunny! The problem is that I am not able to use a diffrent keymap than US, in this case SE. Before you sat the languages by QUACK SET_LANGUAGE se but know according to the new readme in the docs folder you set the languages by DUCKY_LANG=us. With and without QUACK in front of it I don't get it to work. I have copied all the .json languages files from ducky installer to the languages folder, maybe the problem is that I have not installed the languages files correctly. Help would be appreciated. Quote Link to comment Share on other sites More sharing options...
qdba Posted April 9, 2017 Share Posted April 9, 2017 hi copy all the *.json files to the language folder of the bunny flash storage. After them boot into arming mode. During boot all language files will be copied to an internal folder. I think it was /usr/local/lib/language. (At the moment i have no bunny to look at) Quote Link to comment Share on other sites More sharing options...
basi Posted April 10, 2017 Share Posted April 10, 2017 Running into same issues here in the U.K. It makes nearly all payloads impossible to use. Quote Link to comment Share on other sites More sharing options...
elkentaro Posted April 10, 2017 Share Posted April 10, 2017 (edited) yea , same problem for me. Trying to debug the problem now , but it might take a while. Some how the export of the env variable isn't being honored. 2 work arounds I have found so far, both are not ideal but worked for me. 1. In arming mode connect to the bunny via serial and write the DUCKY_LANG env variable in /etc/profile and set it to whatever your target keyboard is DUCKY_LANG=ja the downside is your keyboard settings will be permanent unless you rewrite the profile settings again. i.e.; you lose flexibility in a multilingual environment . 2. If the target is a windows machine you can use the extension I wrote that will change the layout to a en-US layout and you can set it to back to whatever you want after your attack. The downside of this extension is that its a bit slower, making the attack a lesser "smash and grab" attack. See : Technically there is a 3rd option of rewriting the QUACK file itself , but I don't want to or think its a good idea to screw with the core files. Edited April 10, 2017 by elkentaro 1 Quote Link to comment Share on other sites More sharing options...
Sebkinne Posted April 10, 2017 Share Posted April 10, 2017 Hi everyone, From v1.1 onwards, you do not need to assign or export any variables. We created a helper function just for that. Simply execute "DUCKY_LANG us" inside your payload. Just make sure to replace "us" with your language of choice. If QUACK does not type, you most likely don't have the language you chose installed. To install new languages, simply place them inside the languages folder on the Bash Bunny's mass storage partition. The current supported languages can be seen here. If you want to add a language, simply copy us.json to uk.json and make the appropriate changes. We welcome all pull requests that add languages and will be including these in firmware upgrades down the line. Quote Link to comment Share on other sites More sharing options...
elkentaro Posted April 10, 2017 Share Posted April 10, 2017 (edited) @Sebkinne, I think many of have tried it according to the documentation, however the language file does get copied over to the appropriate directory but does not get called in the QUACK script and hence defaults to the us.json cause of : " language = os.getenv("DUCKY_LANG", default="us")" Initially I thought it could be an issue with the [language].json file I build , however even copying over the us.json , change the name and change 1 keycode for testing , still shows that the language file called is the us.json file. Anyway, still digging around to figure out why. (Now , I could be wrong about this...but then again , "exploration" is what hackers do") Edited April 10, 2017 by elkentaro Quote Link to comment Share on other sites More sharing options...
elkentaro Posted April 10, 2017 Share Posted April 10, 2017 I take back what I said. Sorry @Sebkinne. Seems to be an issue with the language file. I just tried again copying the us.json file to another file and change the key codes, and it seem to be working. Quote Link to comment Share on other sites More sharing options...
elkentaro Posted April 10, 2017 Share Posted April 10, 2017 (edited) So, when I used my older [language].json (based off firmware 1.0 us.json) file it doesn't seem to work, however copying the current us.json file under /usr/local/bunny/lilb/languages and modifiying that file , then putting it into the /languages and have the Bunny copy the file to the location it seems to work. So most likely the issue is with the language file. Once the language file is copied over then you can issue the DUCKY_LANG switch in your payload by DUCKY_LANG ja I have attached the ja.json file as an example. if you want to test out wether your language file is valid and working you can change the key code for an alphabetical entry. I choose to switch "a" lowercase and uppercase. "a": "02,00,04", "A": "00,00,04", This is actually the reverse, but it will allow you to check if your language file is being used. hope this helps. Elkentaro. Sample language file. ja.json Edited April 10, 2017 by elkentaro Quote Link to comment Share on other sites More sharing options...
Sebkinne Posted April 10, 2017 Share Posted April 10, 2017 9 minutes ago, elkentaro said: So, when I used my older [language].json (based off firmware 1.0 us.json) file it doesn't seem to work, however copying the current us.json file under /usr/local/bunny/lilb/languages and modifiying that file , then putting it into the /languages and have the Bunny copy the file to the location it seems to work. So most likely the issue is with the language file. Once the language file is copied over then you can issue the DUCKY_LANG switch in your payload by DUCKY_LANG ja I have attached the ja.json file as an example. if you want to test out wether your language file is valid and working you can change the key code for an alphabetical entry. I choose to switch "a" lowercase and uppercase. "a": "02,00,04", "A": "00,00,04", This is actually the reverse, but it will allow you to check if your language file is being used. hope this helps. Elkentaro. Sample language file. ja.json Would love to get a PR from you with the ja.json :) Quote Link to comment Share on other sites More sharing options...
RazerBlade Posted April 10, 2017 Author Share Posted April 10, 2017 Solved the problem! When setting the language in the attack don't use DUCKY_LANG=us, it should instead be DUCKY_LANG us. That was causing the confusion. It would be great if you guys at Hak5 would update the readme in the docs and also the wiki. Quote Link to comment Share on other sites More sharing options...
elkentaro Posted April 10, 2017 Share Posted April 10, 2017 10 minutes ago, Sebkinne said: Would love to get a PR from you with the ja.json :) Thank yea. however I still have some issues with some of the keystrokes. So until I get it all sorted out , I'm holding out. (mainly the issue is with keys that don't exist on a us keyboard , i.e. higher USB HID codes.) But will keep working on it. 1 Quote Link to comment Share on other sites More sharing options...
Sebkinne Posted April 10, 2017 Share Posted April 10, 2017 33 minutes ago, RazerBlade said: Solved the problem! When setting the language in the attack don't use DUCKY_LANG=us, it should instead be DUCKY_LANG us. That was causing the confusion. It would be great if you guys at Hak5 would update the readme in the docs and also the wiki. We are in the process of doing this. Quote Link to comment Share on other sites More sharing options...
basi Posted April 10, 2017 Share Posted April 10, 2017 Thanks this worked!!! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.