Jump to content

cader

Active Members
  • Posts

    11
  • Joined

  • Last visited

Everything posted by cader

  1. THANK YOU!! I'd given up for a bit with the trigger. So I appreciate the write up. I apologize for my sass. I was getting a little frustrated after fruitless debugging of a black box system and I was rude. My bad.
  2. The only device I've been able to detect with both the above script and the included functions has been my neighbors fitbit. My keyboard and phone (both in normal operation, pairing mode, and my phone running multiple kinds of beacon apps) are not detected. So I cracked the device open and discovered the BBmk2 uses an E104-BT52 chip for RX. I don't know enough about bluetooth to speak with authority, but the chip seems to be focused on BLE. I don't know why a normal BT radio was off the table as the device only runs when supplied with USB power and doesn't have the restricted power parameters of normal BLE applications. Maybe it's a firmware or tooling issue. IDK. But I can say for certain that the radio capabilities of the device are early alpha at best. I hope to be proven wrong as this was not a cheap device.
  3. #!/bin/bash function WHY_NO_WORK() { stty -F /dev/ttyS1 speed 115200 cs8 -cstopb -parenb -echo -ixon -icanon -opost stty -F /dev/ttyS1 speed 115200 cs8 -cstopb -parenb -echo -ixon -icanon -opost sleep 1 echo -n -e "AT+ROLE=2" > /dev/ttyS1 echo -n -e "AT+RESET" > /dev/ttyS1 while true; do timeout 1s cat /dev/ttyS1 > /tmp/bt_observation if grep -qao $1 /tmp/bt_observation; then echo "$1 found" else echo "$1 not found" fi done } WHY_NO_WORK 58:A8:F8:A6:C6:69 Is how I've been testing the BT chip after trying the above.
  4. I've also monitored /tmp/bt_observation while running both functions.
  5. So far I have not been able to have success with either of these. Are they BT low energy only? Does the function expect the BT mac address or the device name? I've tried with many combinations of various options and even looked over a hex dump of the output of /dev/ttyS1 Has anyone else been able to make this work? What am I missing?
  6. Ya know? Like restricting the device to fat is a little sucky. It would be nice if the sd card was mounted to /root/udisk at attack time like the 1 sentence documentation says it should be. But it doesn't mount at all. If the card isn't a fat fs, the bb just ignores it completely. MEGA LAME.
  7. Because I was hoping that I was doing something wrong and that passthrough was not the only option for the SD card.
  8. Well it's pretty obvious that it needs a vfat (this includes fat 12, 16, and 32) compatable file system for cross compatability. If the card is formatted as ext4, attack mode storage just presents the internal storage. The sd card is never mounted by the BB, it appears it just offers it as passthrough. I guess this is *fine* but the total abcence of new feature documentation is a little frustrating on a product launch.
  9. I thougth that I would try vfat first because it *should* be able to read it. I ran several default payloads as well as one that was just $echo "test" >> /root/udisk/test.txt The sd has yet to be written to. Any ideas?
  10. Wow, already off the bat rereading that, I feel a little dumb. Yeah, a full scan takes a long time no matter what. I'm sorry. I'm a bad.
  11. So I have started to play around with the new BB mk2. I tried out the official nmapper payload with the additional option -p1-64000 to see how long it would take. It stayed in attack mode for over 30 minutes before I gave up. This is a 7 second scan on my laptop. I'm not expecting that, but I would be nice if it was faster. I also tried -p1-4000 which was a 5 minute scan. Which averages out to 13.5 ports scanned a second. Is this a hardware limitation or is the ethernet emulation firmware a work in progress?
×
×
  • Create New...