I'm trying to interpret a HEX message that is transmitted in network byte order (big endian), how should I proceed to achieve conversion to ASCII?
server.on('message', function (message, remote) {
//I receive message via UDP in HEX.
});
The message comes in this format:
2B 41 43 4B 19 EF 24 10 01 02 03 02 56 50 22 00 0A 02 3B 01 00 00 4E 07 DD 02 17 11 21 20 46 AD 4E 1E 0D 0A
With that being said, each byte has a parameter attached, let's say I have 4 bytes to parameter1, 2 bytes to parameter2 and 8 bytes to parameter 3, how would I interpret it?
Related
I want to modify icmp.unused value in scapy. But no matter what value I set for it, the value of icmp.unused is still 0. I know which byte in my packet is responsible for its value. So I want to modify the byte directly. hexstr and hexdump don't work. The end of the packet is messed up. How to do this?
hex_packet = scapy.hexstr(packet)
print(type(hex_packet))
list_packet = list(hex_packet)
list_packet[38] = '\x05'
list_packet[39] = '\x14'
hex_packet = ''.join(list_packet)
packet_hex = scapy.Ether(scapy.import_hexcap())
08 00 27 78 FE 4B 52 54 00 12 35 00 080 45 00 00 38 00 01 00 00 40 01 31 6D C0 A8 64 01 C0 A8 64 05 03 04 41 5E 00 00 05 14 45 00 00 1C 00 01 00 00 40 11 31 74 C0 A8 64 05 C0 A8 64 06 FC F1 00 35 00 08 B9 5A ..'x.KRT..5...E..8....#.1m..d...d...A^....E.......#.1t..d...d....5...Z
I'm trying to extract the DateTime from a JPEG file's Exif header. I did a quick hex dump to try and locate the Tiff entry. Here's a snippet of the hex dump:
00000000 ff d8 ff e1 27 19 45 78 69 66 00 00 4d 4d 00 2a |....'.Exif..MM.*|
00000010 00 00 00 08 00 0b 01 0f 00 02 00 00 00 06 00 00 |................|
.
.
00000060 00 02 00 00 00 05 00 00 00 b6 01 32 00 02 00 00 |...........2....|
00000070 00 14 00 00 00 bc 02 13 00 03 00 00 00 01 00 01 |................|
.
.
000000b0 78 00 00 00 00 48 00 00 00 01 00 00 00 48 00 00 |x....H.......H..|
000000c0 00 01 31 32 2e 32 00 00 32 30 31 39 3a 30 35 3a |..12.2..2019:05:|
000000d0 31 32 20 31 32 3a 30 32 3a 35 38 00 00 20 82 9a |12 12:02:58.. ..|
So from the hex dump, I know that:
The image is "Motorola" type byte aligned because of (0x4d4d)
The tag is DateTime 0x0132 (address 0x006a to 0x006b)
The tag type is 0x0002 which represents ascii string type (address 0x006c to 0x006d)
The number of components is 0x00000014 which is 20 in decimal(address 0x006e to 0x0071)
The value field, which is the offset to the actual value in this case, is 0x000000bc (address 0x0072 to 0x0075).
Now, if I look at the 20 bytes of value starting from address 0x00bc, it starts off with 0x00, 0x48, 0x00, 0x00, which doesn't represent anything. And it gets cut off at address 0xcf which doesn't include the entire date string. And as you can probably see, the actual date value starts at address 0x00c8 with bytes 0x32 0x30 0x31 0x39 0x3a, which is "2019:" and should continue until address 0xdb.
Can anyone explain why this is happening??
the address of any pointer calculate with base+offset and the base in this case is 0x0C because TIFF header start at 0x0C so 0xBC+0x0C=0xC8 that point to Date, also consider that the end of Date has 0x00 so total length is 20.
you can read more about it at this site.
I copied a piece of text from a website. This piece of text contains a space. I later try to manipulate this string in C#, but my code doesn't recognize the space.
I started digging deeper, so I tried the following Powershell command to convert the string to hexadecimal to see what's going on:
"2+1 53" | Format-Hex
(see screenshot here: Powershell code)
As you can see in the image, it shows that the result is:
32 2B 31 3F 35 33
which converted back to normal text is
2+1?53
Notice that the question mark wasn't present in my original string. What is going on? How can a question mark be present but not show up? Or where did it come from if it was not present in my original string?
Update:
Perhaps I should stress that I need to figure out what that "space" character is, so that I can later get rid of it using "replace" method.
Most likely, there's another character in that text, which is not a space. You can check it by putting the text into a file and then using
Get-Content C:\temp\file.txt | Format-Hex
To reproduce, I used that text:
Get-Service –Name BITS
# ^ it's not a normal dash, check it at http://asciivalue.com/index.php
This happens if I paste into console window:
31.88 ms | C:\> "Get-Service -Name BITS" | Format-Hex
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 47 65 74 2D 53 65 72 76 69 63 65 20 3F 4E 61 6D Get-Service ?Nam
00000010 65 20 42 49 54 53 e BITS
And that when I get it from the script:
60.02 ms | C:\> Get-Content C:\temp\script.ps1 | Format-Hex
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 47 65 74 2D 53 65 72 76 69 63 65 20 3F 3F 3F 4E Get-Service ???N
00000010 61 6D 65 20 42 49 54 53 ame BITS
As you can see, that character is being converted to question mark (3F in hex output) or triple question mark (3F 3F 3F) while getting content from file.
It depends on the version of PowerShell. I have 5.1, there the default encoding of Format-Hex is ASCII, which will replace every non-ASCII character (like your space) with a question mark.
Specify a different encoding to prevent non-ASCII characters from being replaced. Example:
PS> "⇆" | Format-Hex -Encoding Unicode
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 C6 21 Æ!
Here, the code point is U+21C6. Google that and you will find out what it represents.
A regular space is 0x20. There are many unicode spaces. http://jkorpela.fi/chars/spaces.html How did you make the string? Here's an example of EN SPACE (nut), U+2002. You should be able to copy and paste this yourself. Hmm, in powershell 7 for windows, the special space doesn't paste.
[int[]][char[]]'foo bar' | % tostring x
66
6f
6f
2002
62
61
72
'foo bar' | Format-Hex -Encoding BigEndianUnicode
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 00 66 00 6F 00 6F 20 02 00 62 00 61 00 72 .f.o.o ..b.a.r
Format-hex will translate it to ascii by default in powershell 5. Unicode characters will be replaced by 3F or ?.
'foo bar' | format-hex -Encoding ascii
Label: String (System.String) <72F012A4>
Offset Bytes Ascii
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
------ ----------------------------------------------- -----
0000000000000 66 6F 6F 3F 62 61 72 foo?bar
UTF8 will encode in one to three bytes depending on how high the unicode number is (how many bits to encode). Three bytes in this case (U+2002), always starting with 'E' and then the first number, in this case '2'.
' ' | format-hex -Encoding utf8
# "`u{2002}" | format-hex # powershell 7
Label: String (System.String) <03ACFE1C>
Offset Bytes Ascii
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
------ ----------------------------------------------- -----
0000000000000 E2 80 82 �
I found the answer to my question here: String Comparison, .NET and non breaking space
The "space" that was present in the string was the "non-breaking space" and getting rid of it in C# was as easy as:
string cellText = "String with non breaking spaces.";
cellText = Regex.Replace(cellText, #"\u00A0", " ");
I have a Java Card with an applet installed on it that returns the following response when I send 00 40 00 00 to it:
Connect successful.
Send: 00 40 00 00
Recv: 61 32
Time used: 15.000 ms
Send: 00 C0 00 00 32
Recv: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 90 00
Time used: 15.000 ms
The tool that I use (PyAPDUTool), have an option labeled "Auto Get Response". When I check this option, I don't need to send Get Response command (00 c0 00 00 32) anymore:
Send: 00 40 00 00
Recv: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 90 00
Time used: 15.000 ms
Okay. Now I want to have the above behavior on another Java Card. So I wrote the following program:
package testPrjPack;
import javacard.framework.*;
public class TestPrj extends Applet
{
public static byte[] data = {(byte)0x01 ,(byte)0x02 ,(byte)0x03 ,(byte)0x04 ,(byte)0x05 ,(byte)0x06 ,(byte)0x07 ,(byte)0x08 ,(byte)0x09 ,(byte)0x0A ,(byte)0x0B ,(byte)0x0C ,(byte)0x0D ,(byte)0x0E ,(byte)0x0F ,(byte)0x10 ,(byte)0x11 ,(byte)0x12 ,(byte)0x13 ,(byte)0x14 ,(byte)0x15 ,(byte)0x16 ,(byte)0x17 ,(byte)0x18 ,(byte)0x19 ,(byte)0x1A ,(byte)0x1B ,(byte)0x1C ,(byte)0x1D ,(byte)0x1E ,(byte)0x1F ,(byte)0x20 ,(byte)0x21 ,(byte)0x22 ,(byte)0x23 ,(byte)0x24 ,(byte)0x25 ,(byte)0x26 ,(byte)0x27 ,(byte)0x28 ,(byte)0x29 ,(byte)0x2A ,(byte)0x2B ,(byte)0x2C ,(byte)0x2D ,(byte)0x2E ,(byte)0x2F ,(byte)0x30 ,(byte)0x31 ,(byte)0x32};
public static void install(byte[] bArray, short bOffset, byte bLength)
{
new TestPrj().register(bArray, (short) (bOffset + 1), bArray[bOffset]);
}
public void process(APDU apdu)
{
if (selectingApplet())
{
return;
}
byte[] buf = apdu.getBuffer();
switch (buf[ISO7816.OFFSET_INS])
{
case (byte)0x40:
ISOException.throwIt((short)0x6132);
break;
case (byte)0xC0:
Util.arrayCopyNonAtomic(data,(short)0, buf, (short)0, (short)0x32);
apdu.setOutgoingAndSend((short)0,(short)0x32);
break;
default:
ISOException.throwIt(ISO7816.SW_INS_NOT_SUPPORTED);
}
}
}
After installing the .cap file on the new Java Card, I have the following response for both Auto Get Response option checked and unchecked:
As you see above, the Auto Get Response doesn't work anymore and I need to send Get Response command manually.
I'm curious to know what is wrong with this tool or my program? Is the issue related to the communication protocol? (The first card working with T=0 and the second one working with T=1).
Nothing is wrong. T=1 just doesn't use GET RESPONSE at all, so there is no reason for Python to handle it automatically.
Important: note that Java Card also handles the GET RESPONSE automatically, so you should never have to implement it explicitly.
For example: How would one decode the following ethernet frame?
00 26 b9 e8 7e f1 00 12 f2 21 da 00 08 00 45 00 05 dc e3 cd 20 10 35 06 25 eb 0a 0a 0a 02 c0 a8 01 03 c3 9e 0f 40 00 00 10 00 00 00 14 00 70 10 00 5c 59 99 00 00 02 04 05 b4 01 03 03 06 00 00 01 98 64 34 e8 90 84 98 20 12 18 19 04 85 80 00
I know that the first 6 bytes are the MAC destination address : 00 26 b9 e8 7e f1 The next 6 bytes are the source MAC address : 00 12 f2 21 da 00 The next 2 bytes show the ethernet type : 08 00 The next 4 bytes are : 45 00... Ipv4... "5" the number of bytes in the header.. and "00" means there are no differentiated services.
What I don't know is what anything after that is or how to read it.
Anyone help?
Rearranging a bit your packet, we have:
00 26 b9 e8 7e f1 00 12 f2 21 da 00 08 00 45 00
05 dc e3 cd 20 10 35 06 25 eb 0a 0a 0a 02 c0 a8
01 03 c3 9e 0f 40 00 00 10 00 00 00 14 00 70 10
00 5c 59 99 00 00 02 04 05 b4 01 03 03 06 00 00
01 98 64 34 e8 90 84 98 20 12 18 19 04 85 80 00
If you know that the first 6 octets form the destination mac address, that means that it is an Ethernet layer 2 packet.
According to IEEE 802.3, $3.1.1:
First 6 octets are the destination mac address (00 26 b9 e8 7e f1)
Next 6 octets are the source mac address (00 12 f2 21 da 00)
Next 4 octets are, optionally the 802.1Q tag (present, 08 00 45 00)
Next 2 octets are either:
Maximum payload size - aka MTU (if <= 1500, which is the case, 05 dc is 1500)
Ethernet 2 frame (if >= 1536)
Next is the payload ranging from 46 octets (if the 802.1Q tag is absent) or 42 octets (if the 802.1Q tag is present) to up to 1500 octets (starts at e3 cd 20 10 ..., ends either at 20 12 18 19 or at 03 06 00 00, depends on the 7th item)
Last 4 octets form the CRC32 code (either 01 98 64 34 or 04 85 80 00, depending on the 7th item)
There is also 12 octets used for padding (random - not so random - bytes), that may or may not be inserted in this packet. (if inserted, the padding is e8 90 84 98 20 12 18 19 04 85 80 00)