How can I detect the presence or absence of the radiotap data in the raw bytes of a pcap file?
I am not using libpcap but rather examining the payload myself.
It seems to me that I can create a new file with tcpdump that includes this feature but if I'm given a file that may or may not have this feature then it is impossible to determine whether the raw bytes include it or not. The only thing that occurs to me is looking for a difference in the number of bytes in incl_len and orig_len in the pcap data.
By checking the link-layer header type in the pcap file header; if it's 127, then you have radiotap headers followed by 802.11 headers.
The link-layer header type in the pcap file header (and the link-layer header type in an Interface Description Block in a pcap-ng file) has a value that's one of the values given in the tcpdump.org list of link-layer header type values.
The data link type is included in the pcap file header.
From WireShark Doc, you see that the data link type is found in bytes 21-24
typedef struct pcap_hdr_s {
guint32 magic_number; /* magic number */
guint16 version_major; /* major version number */
guint16 version_minor; /* minor version number */
gint32 thiszone; /* GMT to local correction */
guint32 sigfigs; /* accuracy of timestamps */
guint32 snaplen; /* max length of captured packets, in octets */
guint32 network; /* data link type */
} pcap_hdr_t;
Here's an example of a pcap file header with a radio tap header
0xd4 0xc3 0xb2 0xa1
0x02 0x00 0x04 0x00
0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00
0xff 0xff 0x00 0x00
0x7f 0x00 0x00 0x00 --> 0x7f = 127 = LINKTYPE_IEEE802_11_RADIOTAP
0x0d 0x06 0x5c 0x4a
0xee 0x1a 0x02 0x00
0xac 0x00 0x00 0x00
0xac 0x00 0x00 0x00
while in the other example below, we have another link layer type
0xd4 0xc3 0xb2 0xa1
0x02 0x00 0x04 0x00
0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00
0xff 0xff 0x00 0x00
0x69 0x00 0x00 0x00 --> 0x69 = 105 = LINKTYPE_IEEE802_11
0x3a 0xcb 0x38 0x56
0xc5 0x73 0x00 0x00
0xd4 0x00 0x00 0x00
0xd4 0x00 0x00 0x00
Keeping track of our endianness of course :)
Related
I use an ATTiny85 and when I want to flash it with an AVRusb500-smd4 and Arduino IDE. I get this error message:
avrdude: Version 6.3-20201216
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "C:\Users\CPRUVOST\Documents\ArduinoData\packages\ATTinyCore\hardware\avr\1.5.2/avrdude.conf"
Using Port : COM5
Using Programmer : stk500
Setting bit clk period : 5.0
AVR Part : ATtiny85
Chip Erase delay : 400000 us
PAGEL : P00
BS2 : P00
RESET disposition : possible i/o
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 12 4 0 no 512 4 0 4000 4500 0xff 0xff
flash 65 12 32 0 yes 8192 64 128 30000 30000 0xff 0xff
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
calibration 0 0 0 0 no 2 0 0 0 0 0x00 0x00
Programmer Type : STK500V2
Description : Atmel STK500
Programmer Model: STK500
Hardware Version: 2
Firmware Version Master : 2.10
Topcard : Unknown
Vtarget : 5.0 V
SCK period : 8.7 us
Varef : 2.5 V
Oscillator : Off
avrdude: stk500v2_command(): command failed
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.`
I had no problems with my first attempts at flashing etc. And the card works with the latest flashing program. I wanted to make some modifications to improve the behaviour of my prototype. But this message is blocking me.
Do you have any ideas?
I'm leanring low-level Solidity inline assembly, but confused by different output formats.
The ouptut option of Solidity compiler says:
--asm EVM assembly of the contracts.
--opcodes Opcodes of the contracts.
I tried both options to compile the contract below:
// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.4.16 <0.9.0;
contract MyContract {
string bar = "Hello World";
function foo() public view returns(string memory) {
return bar;
}
}
The command solc -o output --asm contract.sol generated MyContract.evm:
/* "contract.sol":70:208 contract MyContract {... */
mstore(0x40, 0x80)
/* "contract.sol":96:122 string bar = "Hello World" */
mload(0x40)
dup1
0x40
add
0x40
mstore
dup1
0x0b
dup2
mstore
0x20
add
0x7657399374655890603765000000000000000000000000000000000000000000
dup2
mstore
pop
0x00
swap1
dup1
mload
swap1
0x20
add
swap1
tag_1
swap3
swap2
swap1
tag_2
jump // in
tag_1:
pop
/* "contract.sol":70:208 contract MyContract {... */
callvalue
dup1
... (and a lot more code)
The command solc -o output --opcodes contract.sol generated MyContract.opcode:
PUSH1 0x80 PUSH1 0x40 MSTORE PUSH1 0x40 MLOAD DUP1 PUSH1 0x40 ADD PUSH1 0x40 MSTORE DUP1 PUSH1 0xB DUP2 MSTORE PUSH1 0x20 ADD PUSH32 0x7657399374655890603765000000000000000000000000000000000000000000 DUP2 MSTORE POP PUSH1 0x0 SWAP1 DUP1 MLOAD SWAP1 PUSH1 0x20 ADD SWAP1 PUSH2 0x4F SWAP3 SWAP2 SWAP1 PUSH2 0x62 JUMP JUMPDEST POP CALLVALUE DUP1 ISZERO PUSH2 0x5C JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST POP PUSH2 0x166 JUMP JUMPDEST DUP3 DUP1 SLOAD PUSH2 0x6E SWAP1 PUSH2 0x105 JUMP JUMPDEST SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 KECCAK256 SWAP1 PUSH1 0x1F ADD PUSH1 0x20 SWAP1 DIV DUP2 ADD SWAP3 DUP3 PUSH2 0x90 JUMPI PUSH1 0x0 DUP6 SSTORE PUSH2 0xD7 JUMP JUMPDEST DUP3 PUSH1 0x1F LT PUSH2 0xA9 JUMPI DUP1 MLOAD PUSH1 ... ...
They look pretty much similar, although not 100% matching each other...
Questions
Does --opcodes just give a more compact form of assembly code compared to --asm output?
PUSH1 0x80 PUSH1 0x40 MSTORE in --opcodes format vs. mstore(0x40, 0x80) in --asm format. Are they doing the same thing? (I guess so but not 100% sure...)
Is there a way to print --opcodes in a pretty format rather than in a single line?
Are there any good resouces to learn Solidity inline assembly? I googled around but found a bunch of one page blogs, which are good to explain the basics but unfortunately none of them gives a complete and in-depth tutorial
1. Does --opcodes just give a more compact form of assembly code compared to --asm output?
That's somewhat correct. You could still translate the assembly to opcodes and get the same result.
Assembly represents a set of "low level-ish" instructions. Opcodes are the "real" binary instructions passed to the EVM. See for example this table that translates the opcodes to binary.
2. PUSH1 0x80 PUSH1 0x40 MSTORE in --opcodes format vs. mstore(0x40, 0x80) in --asm format. Are they doing the same thing? (I guess so but not 100% sure...)
Yes, they are doing the same thing - see answer to 1. When you run this snippet in Solidity
assembly {
mstore(0x40, 0x80)
}
you get the same opcodes.
3. Is there a way to print --opcodes in a pretty format rather than in a single line?
You can use tr on any other text-formatting unix cli command.
echo "PUSH1 0x80 PUSH1" | tr ' ' '\n'
PUSH1
0x80
PUSH1
See this forum post for more ways.
4. Are there any good resouces to learn Solidity inline assembly?
Apart from the documentation, I don't know any, so I'll let someone else give a better answer. But Solidity is still a pretty new technology, so my guess is that most people who specialize in Solidity assembly, learned by trial&error.
In binary we can have a signed and unsigned numbers, so let's say we are given a value of 0101 how could we tell whether it is equal to 5 or to -1 as you may notice the second bit from the left is on
There is no difference in binary. The difference is in how a given language / compiler / environment / processor treats a given sequence of binary digits. For example, in the Intel x86/x64 world you have the MUL and IMUL instructions for multiplication. The IMUL instruction performs signed multiplication (i.e. treats the operand bits as a signed value). There are also other instructions that distinguish between signed/unsigned operands (e.g. DIV/IDIV, MOVSX, etc.).
Here's a quick example:
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
int main(void)
{
int16_t c16;
uint16_t u16;
__asm {
mov al, 0x01
mov bl, 0x8F
mul bl // ax = 0x01 * 0x8F
mov u16, ax
mov al, 0x01
mov bl, 0x8F
imul bl // ax = 0x01 * 0x8F
mov c16, ax
};
char uBits[65];
char cBits[65];
printf("%u:\t%s\n", u16, _itoa(u16, uBits, 2));
printf("%d:\t%s\n", c16, _itoa(c16, cBits, 2));
return 0;
}
Output is:
143: 10001111
-113: 11111111111111111111111110001111
On edit:
Just to expand on the example - in C/C++ (as with other languages that distinguish between signed and unsigned quantities), the compiler knows whether it is operating on signed or unsigned values and generates the appropriate instructions. In the above example, the compiler also knows it must correctly sign-extend the variable c16 when calling _itoa() because it promotes it to an int (in C/C++, int is signed by default - it is equivalent to saying signed int). The variable u16 is promoted to an unsigned int in the call to _itoa(), so no sign-extension occurs (because there is obviously no such thing as a sign bit in an unsigned value).
On actual hardware the implementation of negative numbers is dependent on what the designers chose. Usually signed numbers are represented in Two's Complement
But there are Many More
Have built an NFC-RFID reader interfacing an arduino with an Adobe AIR application.
My confusion is in how to deal with the 4 and 7 byte HEX UID values being returned
example
0xED 0xAD 0x8F 0x9A
or
0x04 0x70 0xE9 0x2A 0x42 0x2B 0x80
Converting a simple HEX value to decimal in AS3 is straightforward, namely
var decimal:int = parseInt("FFFFFF",16); // output : 16777215
But how would I 'massage' the returned RFID HEX values first BEFORE trying to convert using the parseInt method?
I'm trying to build a AS3 socket server that can handshake with html5 websockets. I've base my code on this link https://datatracker.ietf.org/doc/html/draft-ietf-hybi-thewebsocketprotocol-17
This is what i have using the same values as the example in the link:
import com.dynamicflash.util.Base64;
import com.adobe.crypto.SHA1;
function getKey():void{
var key:String = "dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA-C5AB0DC85B11";
key = SHA1.hash(key);
key = Base64.encode(key);
trace(key);
//traces YjM3YTRmMmNjMDYyNGYxNjkwZjY0NjA2Y2YzODU5NDViMmJlYzRlYQ== instead of s3pPLMBiTxaQ9kYGzzhZRbK+xOo="
}
Now the example states that the output should be :
Concretely, if as in the example above, |Sec-WebSocket-Key| header field had the value "dGhlIHNhbXBsZSBub25jZQ==", the server would concatenate the string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" to form the string "dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA-C5AB0DC85B11". The server would then take the SHA-1 hash of this, giving the value 0xb3 0x7a 0x4f 0x2c 0xc0 0x62 0x4f 0x16 0x90 0xf6 0x46 0x06 0xcf 0x38 0x59 0x45 0xb2 0xbe 0xc4 0xea. This value is then base64-encoded (see Section 4 of [RFC4648]), to give the value "s3pPLMBiTxaQ9kYGzzhZRbK+xOo="
Am i missing something ??
Its a while since I've even read any ActionScript but shouldn't you replace
key = SHA1.hash(key);
key = Base64.encode(key);
with
key = SHA1.hashToBase64(key);
? The current code converts the sha1 hash (a byte array) into a string but its the original byte array you need to pass into the base64 encoder.
Let me know if this is of any help:
https://github.com/childoftv/as3-websocket-server