0

I have a Python script that pulls data from a generated .kismet file so that the information is presented in a summarised format. This file is generated when you stop running Kismet and is a SQLite database underneath. When I run my Python script on a file generated on newer versions of Kismet I get errors, whereas an older version works fine. I updated all other libraries and software too. My Python script makes use of the Kismetdb Python wrapper.

I was using SQLite 3027002 and the one I’m using now is SQLite 3038002. I tested both with the new version of Kismet and it made no difference. My original Python version was Python 3.7.3 and new one is Python 3.9.2. I ran my script with both on the new Kismet version and got the same errors.

The Kismet I’m using is 2022-01-R3 and the one before was 2020-12-R3. Changelog didn’t give an answer. The newer Kismet uses database version 8 whereas the older is using version 6 and according to this version 8 introduces the hash and packetid attributes to the packets table within generated Kismet file.

When I call get_all() the error occurs. When I run this with the old Kismet version print(KIS_DEVICES.get_all(**query_args)) outputs all devices, which corresponds to the devices table in the generated Kismet SQLite file (too long to show). That’s what I’m trying to do but with the new Kismet version that uses kismetdb version 8:

import json, sys, kismetdb
from datetime import datetime

# Check if KismetDB is Specified as an Argument
if not len(sys.argv) == 2:
    print("[!] No KismetDB Specified")
    sys.exit(0)

# Set Input and Output Files
KIS_IN = sys.argv[1]
KIS_OUT = "%ssummary" % (KIS_IN[:-6])

query_args = {}
# Get Kismet Devices from DB
KIS_DEVICES = kismetdb.Devices(KIS_IN)
print(KIS_DEVICES.get_all(**query_args))

KIS_DB = [row["device"] for row in KIS_DEVICES.get_all(**query_args)]

sys.exit(0)

The error with the newer Kismet version:

sudo python3 KismetDB_to_Summary\ copy.py new\ pi\ build/Kismet-20220411-23-01-06-1.kismet 
Traceback (most recent call last):
  File "/Users/user/Desktop/Apolloo /KismetDB_to_Summary copy.py", line 53, in <module>
    print(KIS_DEVICES.get_all(**query_args))
  File "/usr/local/lib/python3.9/site-packages/kismetdb/base_interface.py", line 155, in get_all
    return self.get_rows(self.column_names, sql, replacements)
  File "/usr/local/lib/python3.9/site-packages/kismetdb/base_interface.py", line 325, in get_rows
    for row in cur.fetchall():
  File "/usr/local/lib/python3.9/site-packages/kismetdb/utility.py", line 473, in device_field_parser
    retval = json.dumps(json.loads(device))
  File "/usr/local/Cellar/python@3.9/3.9.7/Frameworks/Python.framework/Versions/3.9/lib/python3.9/json/__init__.py", line 341, in loads
    s = s.decode(detect_encoding(s), 'surrogatepass')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf5 in position 1286: invalid start byte

I want to use a newer version of Kismet but still be able to extract and filter the generated SQLite data into my summary output.

user4157124
  • 2,809
  • 13
  • 27
  • 42
SneakyShrike
  • 723
  • 1
  • 10
  • 31
  • 1
    It's actually the json module that is failing and it's because it can't decode the contents of the file. Kismet_devices.get_all is trying to load some json data but can't becuase it's not the proper encoding. What operating system are you user? – Alexander May 07 '22 at 15:12
  • @alexpdev raspberry pi os, but I've also tested it on my mac. – SneakyShrike May 07 '22 at 16:37
  • It seems at least one row in the devices table has a corrupt `device` column; you can try opening the database in the sqlite shell and running `SELECT devkey, device FROM devices` and inspecting the values to see if any look wrong, and manually correcting them. – snakecharmerb May 07 '22 at 16:50
  • @snakecharmerb I can have a look at that, but what is the devkey? – SneakyShrike May 07 '22 at 19:19
  • No idea, probably just a device identifier maybe. – Alexander May 08 '22 at 03:13
  • @snakecharmerb I had a look with DB Browser for SQLite but I wasn't really sure what I was looking for and there were around 2000 entries which made spotting anything very difficult. I wouldn't even know where to look for byte 0Xf5 either. – SneakyShrike May 08 '22 at 20:43

0 Answers0