Jump to content

theDingosBaby

Active Members
  • Content Count

    22
  • Joined

  • Last visited

About theDingosBaby

  • Rank
    Hak5 Fan

Recent Profile Visitors

689 profile views
  1. https://kismetwireless.net/docs/readme/datasources_remote_capture/
  2. Are you using it as a kismet remote, or running kismet standalone on the mk7? Kismet is pretty heavy to run on it standalone. Setup kismet on your laptop, and run the kismet remote capture on the mk7, and see if you can snag it as a data source on your laptop. Should be way more stable that way.
  3. Hmm, weird. I'm curious now. After the long boot, SSH to your mk7, and copy the output from these two commands into a txt file. dmesg logread /tmp/log.db If there are any hardware initialization errors, they should show up there. I can't promise I can help, but if you're down to give a go, open the txt file you made, and scrub out any identifying info you may have in there, SSIDs, MAC address, IPs, hostnames, etc, and then post to here.
  4. You can always dump the output and sort it yourself. The implementation of OUI lookup that hak5 uses already is no different from any other industry standard analysis device. It's based on the kismet lookup routine I believe, but I'm not 100% sure of that. That being said, it's never been an exact science, but if you care you can update the OUI.txt file yourself, in the shell, straight from the source. http://standards-oui.ieee.org/oui.txt IEEE does a reasonably good job of keeping it updated, but in my xp there is a lag between new devices hitting market and those being represented in
  5. BTW, The reason not to trust the power capabilities of your battery pack equally apply to the battery power supply in laptops. They are often made of the same type of cells.
  6. Having used pineapples and other similar devices in mobile engagements, I wouldnt trust that power bank to deliver full 2A if thats all you're using for power, unless you've verified with multi-meter. Even then, current draw can be highly variable from pack to pack, even if the same brand. You could get a USB mAh meter from amazon or something similar to verify, but until then you will get the most consistent results from a proper 2A usb power supply. Also, if you're using your laptop to power the pineapple, you will also have power issues. USB 2.0 ports will only deliver 800mA max. USB 3 i
  7. Without knowing the details of your respective client devices, try to manually set the IP of the interface that is created when you connect the mk7. You'll want to set it to an IP in the 172.16.42.0/24 range, with gateway set to 172.16.42.1 Hope that helps. HH
  8. Lol, what did you do via UART? It's not open source, but I suspect there exists a custom made programming jig, or software that interfaces the NAND flash. It is just speculation at this point, since my reverse engineering chops aren't as good as I'd like, but it won't be long before i figure it out. How familiar are you with OpenWRT devices?
  9. I have some pics of the pcb that show where i think the jtag/programming pads are, but I didn't end up having to do that. Are you certain that it is no longer capable of any DFU access via the ETH micro usb port? I followed this guide using my linux rig, with factory firmware. Then updated to latest build, and got mine running again. http://wiki.wifipineapple.com/#!./troubleshooting.md#Firmware_Recovery
  10. Same, I tried the factory firmware as well. Still getting the same error. I've done the legwork on this issue, I just need a pointer in a direction I may not have anticipated. Not asking anyone to solve this for me. To sum it up: The tetra was running on 1.1.0 and factory firmware previously. After update to 1.1.1 I started getting the 'bad magic number' error. Magic number looks good, and is the same as in the other 2 previous firmware releases. I've tried the update process with 3 different firmwares, and after the flash to 1.1.1 none of them work anymore.
  11. Seb, can you please direct me to any documentation regarding recovery from this issue? I have found a few things in the openwrt documentation, but nothing that specifically regards this issue with the ATH chipset. I am stumped and my tetra is effectively bricked at the moment. Thanks in advance.
  12. I also tried the 1.1.0 firmware again, which it was running on before, and it did the same thing.
  13. Confirmed the NAND data onboard the pineapple matches the header in the 1.1.1 firmware binary. Curiously enough the previous 1.1.0 update worked, with the same header that this one seems to be choking on. " Bad Magic Number 0x73797375 " uboot> nand dump 0x0 Page 00000000 dump: 73 79 73 75 70 67 72 61 64 65 2d 74 65 74 72 61 2f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  14. I have the exact same issue. Except I didn't frag my flash. I attempted to update from 1.1.0 to 1.1.1. This is my serial dump: uboot> reset Resetting... U-Boot 1.1.4 (Dec 22 2015 - 12:54:58) DB120 DRAM: sri Wasp 1.2 wasp_ddr_initial_config(249): (32bit) ddr2 init wasp_ddr_initial_config(426): Wasp ddr init done Tap value selected = 0xf [0x0 - 0x1f] 128 MB Top of RAM usable for U-Boot at: 88000000 Reserving 276k for U-Boot at: 87fb8000 Reserving 192k for malloc() at: 87f88000 Reserving 44 Bytes for Board Info at: 87f87fd4 Reserving 36 By
×
×
  • Create New...