Highlighting problems in Lua dissectors


Here’s a snippet of code that shows how you can highlight problems in Lua dissectors, using add_expert_info

        local item  = tree:add_le(hf_nordic_ble_micok, tvb(UART_PACKET_FLAGS_INDEX, 1), micok > 0)
        if micok == 0 then
            -- MIC is bad
            item:add_expert_info(PI_CHECKSUM, PI_WARN, "MIC is bad")
            item:add_expert_info(PI_UNDECODED, PI_WARN, "Decryption failed (wrong key?)")

NOTE add_expert_info is now deprecated, use add_proto_expert_info instead.

Advertisements

SSL/TLS decryption in Wireshark


Wireshark’s dissector for SSL is able to decrypt SSL/TLS, given the private key in PFX/P12 or PEM format. If you want to figure out whether you’re using the right private key, you can derive the public key from it, and compare its modulus with the first certificate in the chain of certificates sent in the SERVER HELLO.

$ openssl rsa -text -in key.pem -pubout
Private-Key: (2048 bit)
modulus:
00:97:c6:a5:01:d6:36:b3:25:fa:83:9c:93:75:dd:
bb:dc:f6:ef:78:b8:b5:cc:20:1c:35:9a:ba:3d:8d:
d3:94:9b:b0:b2:6c:e7:79:83:3c:07:37:1f:8f:e5:
02:f8:f4:ac:9b:7c:1a:b6:74:6f:73:f5:57:34:30:
5b:32:5a:3b:ba:bd:65:dc:cc:98:30:13:01:fb:0b:
3c:f3:e3:6c:da:9b:3d:47:1f:5f:c3:12:a2:4f:21:
dc:cc:39:90:9d:83:05:b3:06:40:d3:62:25:fe:8b:
e9:1e:ca:a2:d8:0f:9d:cd:84:10:62:15:0e:f3:ab:
cb:d6:fc:92:cf:ff:04:75:17:c6:c7:2d:d6:05:c6:
c1:ce:4e:77:c4:fc:fc:c5:ff:37:4f:83:bb:93:f9:
0f:2f:06:70:6a:55:37:e5:6f:0c:92:5e:14:99:0d:
87:2a:e6:d4:30:f9:de:fb:b5:c6:5e:e8:f5:98:5e:
19:4b:8f:53:8a:e5:f1:87:7b:69:99:4d:a0:55:02:
a0:57:5d:bf:ca:0b:84:8c:23:ed:f6:e5:7a:97:4b:
3e:3f:bb:38:29:0e:11:28:53:6d:d4:d8:69:88:5f:
2d:23:28:e6:43:97:e0:51:db:e8:a8:c7:c5:9f:c3:
9d:11:48:d3:51:8c:5f:ba:ab:c0:60:30:26:e2:c9:
54:8b

wireshark-tls-modulus.png

Wireshark dissector in Lua for custom protocol over WebSockets


It is fairly easy to write a Wireshark dissector in Lua for your custom protocol over WebSockets. To understand the basics of writing, and using, dissectors for Wireshark in Lua, see Create a Wireshark dissector in Lua.

Here’s a template to get you started with writing your custom dissector. Replace port number 8002, with the port number where your WebSocket server listens for incoming connections, and the dissector should be called.

wireshark-websocket.png

You can also register the dissector using declared WebSocket protocol name. Retrieve the ws.protocol dissector table instead of ws.port, and add your dissector to the dissector table using protocol name (a string) instead of port number.

If using WebSockets over SSL/TLS, you need to specify the server’s private key file in SSL protocol dissector‘s configuration, so that Wireshark can decrypt the traffic. The protocol field in configuration should be set to http.

Lua dofile and globals


I have been doing dissector development for Wireshark in Lua for a while now. Lua’s mechanism for reusing code organized across multiple files comes in two flavors, dofile and require. For historical reasons, we’ve been using dofile quite exclusively.

Our dissector files mostly contain global functions, and local or global tables. The tables are used to determine which function should be called to dissect a particular message, to look-up names that map to particular key values, and so on. If a script file needs a function or table in another file, we simply dofile the other file at the top. Lua interpreter will recognize all globals (functions and variables without local) of the other file from that point onwards.

Let’s consider an example. Here’s file1.lua

function f1()
  print("f1 called")
  f2()
end

dofile("file2.lua")

f1()

Here’s file2.lua, located in the same folder as file1.lua

function f2()
  print("f2 called")
end

When you run file1.lua, this is what you get

$ lua file1.lua
f1 called
f2 called

Lua only encounters call to global f2 inside function f1 when we call function f1 towards the end of file1.lua. If we call f1 right at the beginning of file1.lua we get

$ lua file1.lua
lua: file1.lua:2: attempt to call global 'f1' (a nil value)
stack traceback:
	file1.lua:2: in main chunk
	[C]: in ?

If we move dofile towards the end of file1.lua we get

$ lua file1.lua
f1 called
lua: file1.lua:3: attempt to call global 'f2' (a nil value)
stack traceback:
	file1.lua:3: in function 'f1'
	file1.lua:7: in main chunk
	[C]: in ?

Summing it up, a global exists only when Lua has encountered it, whether within the same or another script file.

Let us explore one other characteristic of dofile with another example. This is file1.lua

dofile("file2.lua")
hello['world'] = 'hello!'
print(hello['world'])

function f1()
  print(hello['world'])
  f3()
end

dofile("file3.lua")

f1()

It requires a certain global table in file2.lua, which it updates before using. It also requires a certain function f3 in file3.lua. This is file2.lua

hello = {['hello']='world!'}

function f2()
  print("f2 called")
end

This is file3.lua

dofile('file2.lua')

function f3()
  print('f3 called')
  f2()
end

It needs function f2 in file2.lua. You shouldn’t need dofile because file1.lua has already loaded file2.lua, but whoever coded file3.lua probably doesn’t know that. Let’s execute file1.lua and see what happens

$ lua file1.lua
hello!
nil
f3 called
f2 called

By the time function f1 gets called, the value of key 'world' in the hello table ceases to exist. Why? Because, right before f1 is called, when we dofile file3.lua it will dofile file2.lua. Since file2.lua gets interpreted again, the global hello is replaced by a new table.

Summing it up, Lua will load and execute the same file again when it encounters dofile, redefining all globals in it.

That is why, for reusing code in other script files, use require. Lua will not reinterpret a script file that has already been encountered before. Modifying the example scripts above is straightforward. Replace all dofile with require and drop the lua extension. Thus dofile('file2.lua') will become require('file2'). Execute file1.lua thus

$ export LUA_PATH=$PWD/?.lua
$ lua file1.lua
hello!
hello!
f3 called
f2 called

Globals now work without side-effects! Note the use of LUA_PATH environment variable to specify the search path for Lua scripts. You can also set search path inside a Lua script by modifying package.path.

What if you have already invested in dofile and don’t want to change things for now? In the example above, modifying file2.lua thus, eliminates our problem

if hello == nil then hello = { } end
hello['hello']='world!'

function f2()
  print("f2 called")
end

Wireshark migrating to Qt


Wireshark on Mac OS X is downright ugly. It requires XQuartz, an X11 port for OS X. Wireshark have announced that they have begun a steady migration to Qt. The move has its critics, and backers. I back whatever looks better than it currently does. As Miguel de Icaza of Xamarin points out, it is possible to look good on Mac OS X with the Gtk+ port for Cocoa. So what gives?

Handling TCP keep-alive


Keep-alives are useful in scenarios where either end of a TCP connection disappears without closing the session.

The following script in Python demonstrates sending a keep-alive message when there is no data activity for 60 seconds. If there is no response, 4 additional keep-alive messages are sent at intervals of 15 seconds. If none get a response, the connection is aborted.

Edit the IP address 192.168.0.120 and port to whatever works on your network.

Create a test TCP listener/server using netcat (nc on OS X) on machine with IP address specified in the script

netcat -l 192.168.0.120 8001

Next, run the script

python keepalive.py

It should establish a TCP connection with the listener. Interrupt the network by enabling a firewall, or powering off a router. You’ll see the following when the connection times out

Traceback (most recent call last):
  File "socket_test.py", line 39, in do_work
    req = sock.recv(10)
error: [Errno 110] Connection timed out
Other Socket err, exit and try creating socket again

On OS X or Windows, you can enable keep-alive but cannot set TCP_KEEPIDLE and other parameters. You’ll get the following error message if you try to do so

Traceback (most recent call last):
  File "socket_test.py", line 65, in <module>
    do_work()
  File "socket_test.py", line 19, in do_work
    sock.setsockopt(socket.SOL_TCP, socket.TCP_KEEPIDLE, 60)
AttributeError: 'module' object has no attribute 'TCP_KEEPIDLE'

Wireshark highlights keep-alive messages if TCP sequence number analysis is enabled.

File virtualization in Windows


Windows versions since Vista have a feature in which files with administrative privileges in “Program Files” and other folders, may be masked by a version of the file in user’s Virtual Store. The Virtual Store is located at C:\Users\User_name\AppData\Local\VirtualStore.

If you have changed a file under Program Files using administrative privileges, but find the changes mysteriously fail to have any effect, the Virtual Store may be to blame. I noticed this when editing Wireshark’s init.lua file, but the changes would have no effect. I was able to fix the problem by editing the file stored at the Virtual Store location mentioned above. Certain editors are aware of this Windows feature, when opening and saving a privileged file they use the Virtual Store without informing the user.