I need to find a pattern of 6 pairs of hexadecimal numbers (without 0x), eg.
"00 5a 4f 23 aa 89"
This pattern works for me, but the question is if there any way to simplify it?
[%da-f][%da-f]%s[%da-f][%da-f]%s[%da-f][%da-f]%s[%da-f][%da-f]%s[%da-f][%da-f]%s[%da-f][%da-f]
Lua patterns do not support limiting quantifiers and many more features that regular expressions support (hence, Lua patterns are not even regular expressions).
You can build the pattern dynamically since you know how many times you need to repeat a part of a pattern:
local text = '00 5a 4f 23 aa 89'
local answer = text:match('[%da-f][%da-f]'..('%s[%da-f][%da-f]'):rep(5) )
print (answer)
-- => 00 5a 4f 23 aa 89
See the Lua demo.
The '[%da-f][%da-f]'..('%s[%da-f][%da-f]'):rep(5) can be further shortened with %x hex char shorthand:
'%x%x'..('%s%x%x'):rep(5)
Lua supports %x for hexadecimal digits, so you can replace all every [%da-f] with %x:
%x%x%s%x%x%s%x%x%s%x%x%s%x%x%s%x%x
Lua doesn't support specific quantifiers {n}. If it did, you could make it quite a lot shorter.
Also you can use a "One or more" with the Plus-Sign to shorten up...
print(('Your MAC is: 00 5a 4f 23 aa 89'):match('%x+%s%x+%s%x+%s%x+%s%x+%s%x+'))
-- Tested in Lua 5.1 up to 5.4
It is described under "Pattern Item:" in...
https://www.lua.org/manual/5.4/manual.html#6.4.1
final solution:
local text = '00 5a 4f 23 aa 89'
local pattern = '%x%x'..('%s%x%x'):rep(5)
local answer = text:match(pattern)
print (answer)
Related
Am trying to decode a concatenated String like below ...
SQCB7A750BATWE SQ CB 7 A 750 B A T WE
PT05A1219PY023 PT 05 A 12 19 P Y 023
PT55A1019PX02 PT 55 A 10 19 P X 02
PT33SE2215SW023 PT 33 SE 22 15 S W 023
PT05A2216PW023(LC) PT 05 A 22 16 P W 023 (LC)
am looking for a smarter way rather than hard-coded rules as the input will have variations(number of characters and digits), I came across SEQ2SEQ model and I want to know if it's possible to use it in such problem
I already followed some tutorials to get a taste of it, but the results weren't even close
it also seems there are 2 approaches character level and word level as per this tutorial
Character level:
Input sentence: SQCACA333BA71A
Decoded sentence: P 9(PDD366AZ2IDD4K )F)F(L)L)1)1)1) 6A
-
Input sentence: SQCAAC152DA71A
Decoded sentence: P 9(PDD366AZ2IDD4K )F)F(L)L)1)1)1) 6A
am still trying to implement the word level, but I'd like to know if the problem can be solved using this approach (seq2seq)
I'm trying to add a filter to a field in Wireshak.
My dissector name is: "basic".
it has 3 fields - field1, field2, field3.
each field can have a value of string.
I want that on Wireshark i'll be able to filter by a particular field, for example: basic.field1. (just the same as you look for tcp.len)
How can i do this?
You must declare the fields, assign them to your protocol and add them to the tree when appropriate. There are currently 2 different types of strings supported by Lua, those of type ftypes.STRING, which is used for strings of a known, fixed length, and type ftypes.STRINGZ, which is a NULL (zero)-terminated string, so how you declare the fields will depend upon which of the 2 types they are.
Unfortunately, despite the documentation listing ftypes.UINT_STRING as a supported type, it isn't as can be seen in the source code for wslua_proto_field.c. This type of string is applicable when a length field precedes the string to indicate the length of the string in bytes. In any case, it isn't currently available for Lua-based dissectors.
So, as an example, let's suppose your protocol uses UDP/33333 as its transport and port number, and its 3 fields consist of each of the 3 types of strings described above, namely:
field1: a fixed-length string of 12 bytes.
field2: a NULL-terminated string of arbitrary length.
field3: a counted string preceded by a 2 byte length field in big-endian (network) byte order.
Given these assumptions, the following will dissect the packets:
-- Protocol
local p_basic = Proto("basic", "Basic Protocol")
-- Fields
local f_basic_field1 = ProtoField.string("basic.field1", "Field1")
local f_basic_field2 = ProtoField.stringz("basic.field2", "Field2")
local f_basic_field3 = ProtoField.string("basic.field3", "Field3")
p_basic.fields = { f_basic_field1, f_basic_field2, f_basic_field3 }
-- Dissection
function p_basic.dissector(buf, pinfo, tree)
local basic_tree = tree:add(p_basic, buf(0,-1))
pinfo.cols.protocol:set("BASIC")
basic_tree:add(f_basic_field1, buf(0, 12))
local strz = buf(12):stringz()
local field2_len = string.len(strz) + 1
basic_tree:add(f_basic_field2, buf(12, field2_len))
local field3_len = buf:range(12 + field2_len, 2):uint()
basic_tree:add(f_basic_field3, buf(12 + field2_len + 2, field3_len))
end
-- Registration
local udp_table = DissectorTable.get("udp.port")
udp_table:add(33333, p_basic)
If you want to test this, first save the above lua code to a file such as basic.lua in your personal plugins directory (Found via Help -> About Wireshark -> Folders -> Personal Plugins). You can then use the following hex bytes to test it:
0000 00 0e b6 00 00 02 00 0e b6 00 00 01 08 00 45 00
0010 00 37 00 00 40 00 40 11 b5 ea c0 00 02 65 c0 00
0020 02 66 82 35 82 35 00 23 22 32 48 65 6c 6c 6f 20
0030 77 6f 72 6c 64 21 48 69 20 74 68 65 72 65 00 00
0040 04 42 79 65 21
Save these bytes into a text file, e.g., basic.txt. Start Wireshark and import the file via File -> Import from Hex Dump... -> Filename:basic.txt -> OK. You should see the 3 fields dissected as part of the "Basic Protocol".
For further help with Lua dissectors, you might want to refer to one or more of the following:
Wireshark Lua (wiki page)
Wireshark Lua Examples (wiki page)
Wireshark Lua Dissectors (wiki page)
Wireshark Contributed scripts, macros, colouring rules and plugins (wiki page)
Chapter 10. Lua Support in Wireshark (Wireshark Developer's Guide)
https://www.wireshark.org/docs/wsdg_html_chunked/wsluarm_modules.html (Wireshark Developer's Guide)
Wireshark Lua API Reference Manual Addendum (wiki page)
Lua Directory
Sharkfest '15 presentation and accompanying YouTube video, by Graham Bloice
I considered posting this in reverse engineering but because of the brevity of the question and general irrelevance I decided to post it here.
This may be a really easy question but I haven't been able to find an answer - I should probably read a bit of Lua's source before asking this, but here goes: in a program that has integrated Lua, this is the first few bytes of the buffer being executed:
11 16 A5 F1 9E A8 8B 64 78 8E 2F EA 1C 31 D3 B6 D3 D5 77 23 77 79 1B 73
I've never understood Lua very well, but that doesn't look like byte code. Is there anything else it could be or is it just certainly something custom? I'm pretty sure actual Lua opcodes haven't been modified.
if possible put whole file somewhere. Lua bytecode usualy starts with 1B 4C 75 61 and then some debug infos however there are zeros for spliting of the informations which your sample doesnt have
other way is asking on http://forum.xentax.com/
Put this into a file and try running luac -l filename on it. This will disassemble the binary to the VM instructions.
If it is Lua code you'll get some meaningful output.
So my book says i can define a table of words like so:
table: dw "13,37,99,99"
and that i can snatch values from the table by incrementing the index into the address of the table like so:
mov ax, [table+2] ; should give me 37
but instead it places 0x2c33 in ax rather than 0x3337
is this because of a difference in system architecture? maybe because the book is for 386 and i'm running 686?
0x2C is a comma , and 0x33 is the character 3, and they appear at positions 2 and 3 in your string, as expected. (I'm a little confused as to what you were expecting, since you first say "should give me 37" and later say "rather than 0x3337".)
You have defined a string constant when I suspect that you didn't mean to. The following:
dw "13,37,99,99"
Will produce the following output:
Offset 00 01 02 03 04 05 06 07 08 09 0A 0B
31 33 2C 33 37 2C 39 39 2C 39 39 00
Why? Because:
31 is the ASCII code for '1'
33 is the ASCII code for '3'
2C is the ASCII code for ','
...
39 is the ASCII code for '9'
NASM also null-terminates your string by putting 0 byte at the end (If you don't want your strings to be null-terminated use single quotes instead, '13,37,99,99')
Take into account that ax holds two bytes and it should be fairly clear why ax contains 0x2C33.
I suspect what you wanted was more along the lines of this (no quotes and we use db to indicate we are declaring byte-sized data instead of dw that declares word-sized data):
db 13,37,99,99
This would still give you 0x6363 (ax holds two bytes / conversion of 99, 99 to hex). Not sure where you got 0x3337 from.
I recommend that you install yourself a hex editor and have an experiment inspecting the output from NASM.
I am using DeDe to create an API (Interface) I can compile to. (Strictly legit: while we wait for the vendor to deliver a D2010 version in two months, we can at least get our app compiling...)
We'll stub out all methods.
Dede emits constant declarations like these:
LTIMGLISTCLASS =
00: ÿÿÿÿ....LEADIMGL|FF FF FF FF 0D 00 00 00 4C 45 41 44 49 4D 47 4C|
10: IST32. |49 53 54 33 32 00|;
DS_PREFIX =
0: ÿÿÿÿ....DICM.|FF FF FF FF 04 00 00 00 44 49 43 4D 00|;
How would I convert these into a compilable statement?
In theory, I don't care about the actual values, since I doubt they're use anywhere, but I'd like to get their size correct. Are these integers, LongInts or ???
Any other hints on using DeDe would be welcome.
Those are strings. The first four bytes are the reference count, which for string literals is always -1 ($ffffffff). The next four bytes are the character count. Then comes the characters an a null terminator.
const
LTIMGLISTCLASS = 'LEADIMGLIST32'; // 13 = $0D characters
DS_PREFIX = 'DICM'; // 4 = $04 characters
You don't have to "doubt" whether those constants are used anywhere. You can confirm it empirically. Compile your project without those constants. If it compiles, then they're not used.
If your project doesn't compile, then those constants must be used somewhere in your code. Based on the context, you can provide your own declarations. If the constant is used like a string, then declare a string; if it's used like an integer, then declare an integer.
Another option is to load your project in a version of Delphi that's compatible with the DCUs you have. Use code completion to make the IDE display the constant and its type.