There is an inconsistency in the UI.

Both for "Rogue AP" and "Deauth" you want to select a wifi Network and do something on it (or like it). For "Rogue AP" you have a button to select an SSID to mock, and then you can start or stop the "Rogue AP". The button to "Sel.AP" start a selection window with it's OK button.

For "Deauth" there is no dedicated menu, you are on the list of scanned network, and you can select one to do your attack. This is not consistent.

Options:

• Remove the "Deauth" option from the WiFi Network screen, and make a Deauth menu identical to the Rogue AP menu. That way it is identical experience and the WiFi Network screen is read only and not an attack screen (like the channel utilisation) and it is possible to compile the HackWatch without the attack feature.
• Remove the "Rogue AP" screen and make the selection of attack after the selection of "WiFi Network". So once a network is selected you would have the option to either do "Deauth" or "Rogue AP" or "Nothing"

Right now, I prefer the first option, with dedicated screen for "Deauth" and "Rogue AP", also because the "Deauth" and/or the "Rogue AP" could run in the background (?), just like "TV B Gone", so it is useful to have a dedicated screen for each (where the attack can be stopped).

Hi! I run idf.py build and get such error

hackwatch/components/twatch-lib/drivers/i2c.c:3:10: fatal error: driver/gpio.h: No such file or directory
    3 | #include "driver/gpio.h"
      |          ^~~~~~~~~~~~~~~
compilation terminated.
[2/71] Performing build step for 'bootloader'
[1/1] cd /home/reinethernal/firmware/hackw2/hackwatch/build/bootloader/esp-idf/esptool_py && /home/reinethernal/.espressif/python_env/idf5.0_py3.10_env/bin/python /home/reinethernal/esp/esp-idf/components/partition_table/check_sizes.py --offset 0x8000 bootloader 0x1000 /home/reinethernal/firmware/hackw2/hackwatch/build/bootloader/bootloader.bin
Bootloader binary size 0x6610 bytes. 0x9f0 bytes (9%) free.
ninja: build stopped: subcommand failed.
ninja failed with exit code 1
root@re:/home/reinethernal/firmware/hackw2/hackwatch#

In "Wifi Network", when selecting an SSID, you get into the only part of the UI that cannot be escaped without using the watch button. For a user no knowing, that make the "Deauth" button the only option. :-) For every other UI you can escape by swiping one direction or another, of for "Rogue AP" you can escape pressing the OK button. Options:

• Offer a "Deauth" and a "Cancel" button so that there is an alternative way to get out.
• Make it possible to escape by swiping the screen (but then it is not modal like in "Rogue AP").

In AP selection from "Rogue AP" there are visual glitch:

• The white border is missing from the right of the screen and a bleu line is visible instate.
• The blue line is not complete and interrupted at the top, where the elevator is present. (a picture would be best)

Lors du lancement du deauth le bouton passe avec le label "stop", en laissant le deauth actif et si on revient sur la liste des ssid visible et qu'on sélectionne un autre ssid le bouton deauth reste sur "stop". Si beaucoup de ssid actif (notamment pour les spots wifi avec le même ssid à plusieurs émetteurs différents adresses macs) il n'est pas possible d’identifier sur quel ssid le deauth est actif.

Peut-être envisager de mettre un fond ou une couleur différents,dans la liste des ssid, sur le ssid où le deauth est actif afin d'identifier ce dernier ?

After my first tests, I find that it makes more sense to switch to the min value when we reach the max value and vice versa, this avoids sliding in the other direction.

What do you think about it ?

The current "About" say T-Watch 2020 v1/v2 compatible firmware providing WiFi and BLE testing tools (and also, a watch :D)

It should be updated as to not exclude v3 watch. Either do not specift v1/v2 or write v1/v2/v3.

Also it say Wifi and BLE, but does not talk about IR.

I have been using the watch in "war driving" mode: Keeping the Network tile open and driving near homes.

Pretty quickly the screen stop updating, no new network and visible network do not disappear even if very far away.

I am afraid that by testing in a stable/static location, some problems could go unnoticed. Maybe we need to add and remove SSID and check how/when the info is updated.

Not a big issue for my use case, going somewhere with the watch turned off and turning it on in the place where I want to use it.

When in "BLE Devices" with a lot of MAC, there is the option to scroll up. However, scrolling up make an erasing line visible on top of the text "BLE Devices". The line start from the middle of the "B" until the end on the right. The line scroll at the same speed as the list of MAC. It could be an invisible separator between MACs, that somehow goes outside of the bounding box? I'll try attaching a picture.

Hi,

I noticed that the twatch freezes when you activate or deactivate the wifi scanner and one is forced to do a hard reset. We can also see that the sliding between the scanner tile and the channels tile is not fluid.

The problem is random, it occurs more easily when quickly changing between WiFi tiles.

Hi Virtualabs, I've been using the Hackwatch for a while and there was a little thing that bothered me, the absence of the modal for saving the date as for the time, so I added it :D

If you change the contrast or the screen rotation and turn off completely the watch (6 seconds on the physical button) and then restart the watch (2 seconds on the physical button), the contrast and rotation return to default value.

In "Rogue AP" if there is no Target selected, what should the Start button do?

Right now it click (turn white) and vibrate when pushing.

Options for when no target are defined:

• Keep like that
• Grey out the button
• Make the button non reactive (not turning white and not vibrating)
• Do not show the button and only show the "Sel. AP"

I have this error at the linking step

C:\Users\f.lecoufle\Documents\github\hackwatch>idf.py build Executing action: all (aliases: build) Running ninja in directory c:\users\f.lecoufle\documents\github\hackwatch\build Executing "ninja all"... [1/6] Performing build step for 'bootloader' [1/1] cmd.exe /C "cd /D C:\Users\f.lecoufle\Documents\github\hackwatch\build\bootloader\esp-idf\esptool_py && C:\Espressif\python_env\idf4.4_py3.8_env\Scripts\python.exe C:/Espressif/frameworks/esp-idf-v4.4/components/partition_table/check_sizes.py --offset 0x8000 bootloader 0x1000 C:/Users/f.lecoufle/Documents/github/hackwatch/build/bootloader/bootloader.bin" Bootloader binary size 0x62c0 bytes. 0xd40 bytes (12%) free. [2/4] Linking CXX executable hackwatch.elf FAILED: hackwatch.elf cmd.exe /C "cd . && C:\Espressif\tools\xtensa-esp32-elf\esp-2021r2-patch2-8.4.0\xtensa-esp32-elf\bin\xtensa-esp32-elf-g++.exe -mlongcalls -Wno-frame-address @CMakeFiles\hackwatch.elf.rsp -o hackwatch.elf && cd ." c:/espressif/tools/xtensa-esp32-elf/esp-2021r2-patch2-8.4.0/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld.exe: hackwatch.elf section .dram0.bss' will not fit in regiondram0_0_seg' c:/espressif/tools/xtensa-esp32-elf/esp-2021r2-patch2-8.4.0/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld.exe: DRAM segment data does not fit. c:/espressif/tools/xtensa-esp32-elf/esp-2021r2-patch2-8.4.0/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld.exe: DRAM segment data does not fit. c:/espressif/tools/xtensa-esp32-elf/esp-2021r2-patch2-8.4.0/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld.exe: region `dram0_0_seg' overflowed by 2168 bytes collect2.exe: error: ld returned 1 exit status ninja: build stopped: subcommand failed. ninja failed with exit code 1

Any idea ?