Below is a section from the dmidecode output. There is a part of this section that I want to break down. I want to get the 4 bytes after pattern 01 85 30. And I want to change the byte order. Then I will compare with the hex strings I have.
.......
Handle 0x0027, DMI type 219, 106 bytes
OEM-specific Type
Header and Data:
DB 6A 27 00 01 04 01 45 02 00 90 06 *01 85 30* 20
00 00 00 00 40 00 00 03 1F 24 02 C9 02 60 44 02
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF 03 00 00 00 80 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 04 FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF
.......
Expected output : 00000020
I prepared a bash script and it works, is there a better way?
#!/bin/bash
id_array=("00000020", "00000040")
unique_id=$(dmidecode -t 219 | grep "01 85 30" -A 1 | xargs | cut -c 46-56 | tr -d '[:space:]' | grep -o .. | tac | paste -sd '' -)
if [[ " ${id_array[*]} " == *"$unique_id"* ]];
then
echo "1"
else
echo "0"
fi
I would harness GNU AWK for this task following, let command give output
Handle 0x0027, DMI type 219, 106 bytes
OEM-specific Type
Header and Data:
DB 6A 27 00 01 04 01 45 02 00 90 06 01 85 30 20
00 00 00 00 40 00 00 03 1F 24 02 C9 02 60 44 02
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF 03 00 00 00 80 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 04 FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF
.......
then
command | awk 'BEGIN{RS="01[[:space:]]85[[:space:]]30"}NR>1{print $4 $3 $2 $1}'
gives output
00000020
Explanation: I inform GNU AWK that row separator (RS) is given sequence, I use [[:space:]] rather than just space to allow situations when sequence does go through multiple lines, then for each line beyond 1st I print 4th field concatenated with 3rd field with 2nd field with 1st field.
(tested in GNU Awk 5.0.1)
Awk solution allowing for line breaks that might disrupt the search pattern and the byte values being sought.
I've used two short awk procedures pipped together. The first formats the data such that the search pattern and following bytes are always separated by a single space, without line breaks, or any tabs or runs of spaces.
The second procedure divides the data at the now clean pattern set and extracts the first four bytes of the second record (the part immediately following the pattern), and prints them in reverse order.
whole procedure (file contains the original data)
awk 'BEGIN{ORS=" "; OFS=" "} {gsub(FS," ",$0); $1=$1; print$0}' file | awk -v pattern="01 85 30" 'BEGIN{RS=pattern} NR==2{print $4" "$3" "$2" "$1}'
output
00 00 00 20
Explanation of parts
part 1
takes the data file file and re-formats to produce an output that contains each white-space separated 'word' of the input file but now separated by a single space.
awk 'BEGIN{ORS=" "; OFS=" "} {gsub(FS," ",$0); $1=$1; print$0}' file |
This is achieved by setting both the output record separator ORS and output field separator OFS to a single space in the BEGIN block. The main block then substitutes the default input field separatorFS (white space of any length) for a single space character in each record, using gsub(FS," ",$0);. The record (line) is then printed (print $0) after forcing awk to reevaluate it (using $1=$1) to prevent the line being passed as it was received.
The output of the first part is:
Handle 0x0027, DMI type 219, 106 bytes OEM-specific Type Header and Data: DB 6A 27 00 01 04 01 45 02 00 90 06 01 85 30 20 00 00 00 00 40 00 00 03 1F 24 02 C9 02 60 44 02 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 03 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
and is piped directly to the second awk procedure
part 2
| awk -v pattern="01 85 30" 'BEGIN{RS=pattern} NR==2{print $4" "$3" "$2" "$1}'
uses the variable flag v to pass the search pattern into the awk procedure -v pattern="01 85 30" allowing the combined procedure to be called repeatedly from a shell command if many patterns are to be processed (by setting the pattern to a shell variable and using the variable name in place of the string "01 85 30").
A BEGIN block sets the record separator to be the passed pattern (RS=pattern) so that subsequent blocks will examine chunks of the file either side of the pattern as individual records.
Since the required data immediately follows the pattern we are only interested in the second record so the main awk block filters for record 2 (NR==2), printing the first four fields in reverse order, separated by single spaces, with print $4" "$3" "$2" "$1
Related
I want to write to a mifare classic 4k, using the following APDU command (UPDATE BINARY):
APDU = {FF D6 00 20 10 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0Fh}
It seems fine as a get a 90 00 result...
but when i read the card back I always got the following (even with different data...):
sector: 8 (block 32), auth OK
032: D5 41 00 EA 00 FF 13 3E 86 6A 00 00 00 00 69 FF
033: D5 41 00 EA 00 FF 13 3E 86 6A 00 00 00 00 69 FF
034: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
035: 00 00 00 00 00 00 FF 07 80 69 FF FF FF FF FF FF
where does this string D5 41 00 EA 00 FF 13 3E 86 6A 00 00 00 00 69 FF come from?
Note that i didn't change any setting on the card and was properly authenticated. It was a blank card and i didn't touch the trailer.
I m using a ACR122 reader (this command comes direct from the documentation of the reader...)
Ok i found my problem, i was setting the wrong size for the cbSendLength parameter in SCardTransmit.
Now i set the correct one (the whole size of the APDU command: 21) and it works fine.
Sorry.
I currently took a photo with a camera which returned to me all its values in decimal and after extracting the values my jpeg file are(i converted them to hex here but they were still saved in decimal)
FF
D8
FF
FE
00
24
30
00
9D
08
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
F0
00
40
01
0C
00
32
............
00
54
65
6B
D9
9F
FF
FF
D9
i saved theses value into a file called image.jpg (they were saved in decimal)
however the image file was not able to read it and I can not use the linux command convert as it tells me "Bogus marker length". What would i be doing wrong that doesnt allow me to see the image?
So, I'm trying to understand how PNG to BMP conversion actually takes place. I created the following 8x8 pixel PNG using a tool online:
I then performed a conversion using the ImageMagik tool in OSX terminal:
$ convert -monochrome pic.png pic.bmp
Afterwards, I did a hexdump of the image:
$ hexdump -C pic.bmp
00000000 42 4d 4a 01 00 00 00 00 00 00 8a 00 00 00 7c 00 |BMJ...........|.|
00000010 00 00 08 00 00 00 08 00 00 00 01 00 18 00 00 00 |................|
00000020 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 ff 00 00 ff 00 00 ff 00 |................|
00000040 00 00 00 00 00 ff 42 47 52 73 8f c2 f5 28 51 b8 |......BGRs...(Q.|
00000050 1e 15 1e 85 eb 01 33 33 33 13 66 66 66 26 66 66 |......333.fff&ff|
00000060 66 06 99 99 99 09 3d 0a d7 03 28 5c 8f 32 00 00 |f.....=...(\.2..|
00000070 00 00 00 00 00 00 00 00 00 00 04 00 00 00 00 00 |................|
00000080 00 00 00 00 00 00 00 00 00 00 ff ff ff ff ff ff |................|
00000090 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000130 ff ff 00 00 00 ff ff ff ff ff ff ff ff ff ff ff |................|
00000140 ff ff ff ff ff ff ff ff ff ff |..........|
0000014a
So, obviously we have a BMP header from 0x00 - 0x8C. Then we have FF for white pixels and 00 for black. That all makes sense, but the structure of the output doesn't. So far, it seems that there is a 3 to 1 ratio. 3 bytes per pixel. I'm assuming this means black, white, no-color?
I need to fully understand why there are 3 bytes per pixel instead of 2. Ideally, I would like a binary 1 or 0 for each pixel instead. Is there a way to do this? And if not, can someone please explain the layout of bytes? Specifically: Why are the 3 00s at 0x132 - 0x134 and not the very beginning?
Thanks
Imagemagick, in fact, does support 1-bit BMP, if using either BMP3 or BMP2 formats, but not BMP4 which is just BMP. So if you want 1-bit depth per channel, then do
Input:
convert image.png -depth 1 BMP3:result.bmp
If you want a 1-bit depth for the whole image (i.e. binary), then do
convert image.png -depth 1 -type bilevel BMP3:result2.bmp
Or
convert image.png -depth 1 -threshold 50% BMP3:result3.bmp
I'm not sure which question this will answer, but from the Usage docs
IM can not produce BMP's at depth levels other than 8. However you can
use NetPBM image processing set to do the final conversion to other depth
levels (This needs at least a Q16 version of IM)...
So if we leverage NetPBM
$ convert pic.png -depth 1 ppm:- | hexdump
Which gives (Note the values are 0 & 1, but you still have a RGB channels)
0000000 50 36 0a 38 20 38 0a 31 0a 00 00 00 01 01 01 01
0000010 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
*
00000c0 01 01 01 01 01 01 01 01 01
00000c9
So a workaround my be as simple as
$ convert pic.png -depth 1 ppm:- | pnmdepth 1 | ppm2bmp > pic.bmp
On Fedora 27 that command is:
$ convert pic.png -depth 1 ppm:- | pnmdepth 1 | ppmtobmp > pic.bmp
You need:
$ dnf install netpbm-progs
I am trying to use a PN532(NFC controller). Lately something in my SPI-communication is off. I start comunication by asking for the firmewareversion (D4 02). Next I try to set the SAM-Config. But the PN532 wont give an ACK nor an response.
What I observed is this. (all in hex)
GetFirmewareversion --- ACK<br>
MOSI: 01 00 00 FF 02 FE D4 02 2A 00 --- 02 00 03 00 00 00 00 00 00<br>
MISO: 00 FF FF FF FF FF FF FF FF FF --- FF 01 01 00 00 FF 00 FF 00
Receive Firmewareversion after ACK<br>
MOSI: 02 00 03 00 00 00 00 00 00 00 00 00 00 00 00<br>
MISO: 00 01 01 00 FF 06 FA D5 03 32 01 06 07 E8 00
Set SAMConfig --- see if ready(endless)<br>
MOSI: 01 00 00 FF 05 FB D4 14 01 14 01 02 00 --- 02 00 --- 02 00 --- 02 00<br>
MISO: AA AA AA AA AA AA AA AA AA FF FF FF FF --- FF 00 --- 00 00 --- 00 00
When I write my getFiremware he responds 0xFF, but when i try to set SAM he always responds with 0xAA. He also never replies an ACK or response to setSAMConfig.
Where is my Mistake? where is this Coming from? How to fix it?
THX in advance.
Insert some delay after asserting the PN532 chip select.
Had the same problem, this works for me:
void pn532_select (void)
{
FIO2CLR = PN532_CS; // assert CS
msleep (1); // relax a bit
}
I have problem with use direct command for mifare 1k via ACR122U. I use original SDK for Windows (including for delphi), and I sent these commands in one session:
FF 00 00 00 means pseudo-apdu. It is used to send direct commands to tag or to device (ACR).
<< FF 00 00 00 02 D4 02 // GET FIRMWARE
>> D5 03 32 01 06 07 90 00
<< FF 00 00 00 03 D4 12 24 // SET PARAMETERS (I want to disable not suported ISO 14443-4)
// (I also tried D2 12 14 without success)
>> D5 13 90 00
<< FF 00 00 00 0F D4 40 01 60 00 FF FF FF FF FF FF xx xx xx xx // auth with key A (tag UID hidden)
>> D5 41 00 90 00 // OK
<< FF 00 00 00 05 D4 40 01 30 00 // direct mifare read (30) block 00
>> D5 41 13 90 00 // ERROR 13 (incorrect value of PCB or PFB, invalid or unexpected received frame, NAD or DID incoherence, bad length of received RF frame).
I cannot read any card (i have three). All cards can be read with command FF B0 00 00 10...
Can you please tell me, what command(s) shall be sent before and after authentification to correctly communicate with the card? Please also send links to specification of commands Read register (D4 06) and write register (D4 08). I don't know what means register "63 05" (D4 06 63 05) for example.
BTW. What mean abbreviations (in context): NAD, DID, PFB, PCB?