I'm implementing a PNG encoder in VHDL for learning purposes. It works with image sizes from 1x1 to 4x4. At the image size of 5x5 there is a behaviour I can't understand:
When encoding raw data with values 0...24, the encoding works. However, when using raw data with values 255...231, it generates a broken image.
Input values 0...24:
> hexdump -C png_encoder/gen/test_img_no_compression_5x5.png
00000000 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 |.PNG........IHDR|
00000010 00 00 00 05 00 00 00 05 08 00 00 00 00 a8 04 79 |...............y|
00000020 39 00 00 00 4c 49 44 41 54 78 01 00 04 00 fb ff |9...LIDATx......|
00000030 00 00 01 02 00 04 00 fb ff 03 04 00 05 00 04 00 |................|
00000040 fb ff 06 07 08 09 00 04 00 fb ff 00 0a 0b 0c 00 |................|
00000050 04 00 fb ff 0d 0e 00 0f 00 04 00 fb ff 10 11 12 |................|
00000060 13 00 04 00 fb ff 00 14 15 16 01 02 00 fd ff 17 |................|
00000070 18 0b a4 01 2d d5 1f a2 6d 00 00 00 00 49 45 4e |....-...m....IEN|
00000080 44 ae 42 60 82 |D.B`.|
00000085
> pngcheck -vv png_encoder/gen/test_img_no_compression_5x5.png
File: png_encoder/gen/test_img_no_compression_5x5.png (133 bytes)
chunk IHDR at offset 0x0000c, length 13
5 x 5 image, 8-bit grayscale, non-interlaced
chunk IDAT at offset 0x00025, length 76
zlib: deflated, 32K window, superfast compression
row filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
0 0 0 0 0 (5 out of 5)
chunk IEND at offset 0x0007d, length 0
No errors detected in png_encoder/gen/test_img_no_compression_5x5.png (3 chunks, -432.0% compression).
Input values 255...231:
> hexdump -C png_encoder/gen/test_img_no_compression_5x5.png
00000000 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 |.PNG........IHDR|
00000010 00 00 00 05 00 00 00 05 08 00 00 00 00 a8 04 79 |...............y|
00000020 39 00 00 00 4c 49 44 41 54 78 01 00 04 00 fb ff |9...LIDATx......|
00000030 00 ff fe fd 00 04 00 fb ff fc fb 00 fa 00 04 00 |................|
00000040 fb ff f9 f8 f7 f6 00 04 00 fb ff 00 f5 f4 f3 00 |................|
00000050 04 00 fb ff f2 f1 00 f0 00 04 00 fb ff ef ee ed |................|
00000060 ec 00 04 00 fb ff 00 eb ea e9 01 02 00 fd ff e8 |................|
00000070 e7 6a 21 17 bc 9a 17 87 e7 00 00 00 00 49 45 4e |.j!..........IEN|
00000080 44 ae 42 60 82 |D.B`.|
00000085
> pngcheck -vv png_encoder/gen/test_img_no_compression_5x5.png
File: png_encoder/gen/test_img_no_compression_5x5.png (133 bytes)
chunk IHDR at offset 0x0000c, length 13
5 x 5 image, 8-bit grayscale, non-interlaced
chunk IDAT at offset 0x00025, length 76
zlib: deflated, 32K window, superfast compression
row filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
zlib: inflate error = -3 (data error)
(0 out of 5)
ERRORS DETECTED in png_encoder/gen/test_img_no_compression_5x5.png
How to interpret the error message zlib: inflate error = -3 (data error)?
I read https://www.zlib.net/zlib_how.html, but didn't find more specific information. My first guess was the row filters are incorrect, but since both files are structured the same, this is unlikely. Is there something wrong with the ADLER32 calculation in the second case (possibly some overflow)?
It was an overflow in the ADLER32 checksum calculation. Specifically, there were two 16 bit numbers added and truncated before applying the modulo with 65521. Unfortunately my ADLER32 unittest didn't catch it, yet.
However, the error message was shown several times during the implementation and I was always not sure about the cause. If anybody could elaborate the error message or explain how to get a better error message, I would be glad to hear it.
I'm currently working on an old MS-DOS application, which uses DMI to identify the hardware. It worked fine in the past, but it seems to provide invalid data on newer systems (e.g. Skylake). As stated in the spec, we are scanning 0xF0000-0xFFFFF for the "SM" anchor string, this is still working as expected.
But now it seems that the data located at the "Structure table adress" (stored at offset 0x18h in the) are invalid (see dumps below). Tools like dmidecoe deliver correct information (however, it uses GetSystemFirmwareTable() on Windows). What I am doing wrong here?
EDIT (clarify situation)
On an older system I get expected data (dump is done in FreeDOS' debug98 utility) - following come from an IvyBridge system (3rd gen.):
-d F000:04C0
F000:04C0 5F 53 4D 5F 03 1F 02 07-77 00 00 00 00 00 00 00 _SM_....w.......
F000:04D0 5F 44 4D 49 5F E0 6E 04-10 BA 0E 00 17 00 27 00 _DMI_.n.......'.
F000:04E0 1E 66 60 68 00 F0 1F B8-90 D0 83 C0 0F 24 F0 A3 .f`h.........$..
F000:04F0 1D 03 B9 00 E0 2B C8 79-02 33 C9 89 0E 1F 03 33 .....+.y.3.....3
F000:0500 C0 66 2E 8B 1E 63 00 66-83 FB 00 74 0B 66 81 FB .f...c.f...t.f..
F000:0510 00 00 0E 00 72 02 8B C3-A3 19 03 F7 D0 A3 1B 03 ....r...........
F000:0520 66 61 1F C3 00 1E 50 68-00 F0 1F 0B DB 74 28 F7 fa....Ph.....t(.
F000:0530 C3 80 00 74 1C 2E 80 3E-24 05 00 75 43 83 F9 3E ...t...>$..uC..>
-d E000:BA10
E000:BA10 00 18 00 00 01 02 00 F0-03 7F 80 98 89 3F 01 00 .............?..
E000:BA20 00 00 03 0D 04 06 FF FF-41 6D 65 72 69 63 61 6E ........American
E000:BA30 20 4D 65 67 61 74 72 65-6E 64 73 20 49 6E 63 2E Megatrends Inc.
E000:BA40 00 42 51 37 37 52 31 31-31 00 30 37 2F 30 35 2F .BQ77R111.07/05/
E000:BA50 32 30 31 33 00 00 01 1B-01 00 01 02 03 04 00 00 2013............
E000:BA60 01 26 60 24 00 05 00 06-00 07 00 08 00 09 06 05 .&`$............
E000:BA70 06 20 00 20 00 20 00 30-30 30 30 30 31 32 36 36 . . . .000001266
E000:BA80 30 32 34 00 20 00 20 00-00 02 0F 02 00 01 02 03 024. . .........
Newer systems - in this case a Skylake based one (6th gen.) data are different. In the adress the SMI structure points to i do not get the expected data (I expcted to see the BIOS strings, but they are not there):
-d f000:05e0
F000:05E0 5F 53 4D 5F F3 1F 03 00-8C 01 00 00 00 00 00 00 _SM_............
F000:05F0 5F 44 4D 49 5F 15 CE 07-00 90 1D 87 1A 00 30 00 _DMI_.........0.
F000:0600 5F 53 4D 33 5F 4A 18 03-00 00 01 00 CE 07 00 00 _SM3_J..........
F000:0610 00 90 1D 87 00 00 00 00-00 00 00 00 00 00 00 00 ................
F000:0620 1E 66 60 68 00 F0 1F B8-00 C6 83 C0 0F 24 F0 A3 .f`h.........$..
F000:0630 8E 03 B9 00 E0 2B C8 79-02 33 C9 89 0E 90 03 33 .....+.y.3.....3
F000:0640 C0 66 2E 8B 1E 63 00 66-83 FB 00 74 0B 66 81 FB .f...c.f...t.f..
F000:0650 00 00 0E 00 72 02 8B C3-A3 8A 03 F7 D0 A3 8C 03 ....r...........
-d 871d:9000
871D:9000 76 06 D1 E9 73 08 8A 05-A4 88 44 FF 74 08 8B 05 v...s.....D.t...
871D:9010 A5 89 44 FE E2 F8 5F 5E-5D C2 04 00 55 8B EC 4C ..D..._^]...U..L
871D:9020 4C 56 57 83 7E 04 02 73-2D 83 7E 04 02 74 03 E9 LVW.~..s-.~..t..
871D:9030 18 01 8B 46 06 03 06 AC-10 8B F8 50 FF 76 06 FF ...F.......P.v..
871D:9040 16 AE 10 59 59 0B C0 7F-03 E9 FE 00 FF 76 06 57 ...YY........v.W
871D:9050 E8 9D FF E9 F4 00 8B 46-04 48 F7 2E AC 10 8B 56 .......F.H.....V
871D:9060 06 03 D0 8B FA 8B 46 04-D1 E8 F7 2E AC 10 8B 56 ......F........V
871D:9070 06 03 D0 8B F2 57 56 FF-16 AE 10 59 59 0B C0 7E .....WV....YY..~
Your SMBIOS structures are located at physical address 0x871d9000 (as seen from offset f000:0610, or offset x10 from the '_SM3_' anchor string), as Michael Petch points out.
This is a minor point but could be important depending on how your software is constructed. Keep in mind this is a SMBIOS 3.0 conforming structure (per the "_SM3_" anchor string) and that the structure table address can be on any 64-bit address. To ensure your software works in all systems, you should use the _SM3_ structure table address when present and enable your software to read any 64-bit physical address using big-real mode or other mechanism. When the _SM3_ structure is not present, then revert back to your old software flow.
As for why you are just now seeing this, is this the first time you have encountered a data structure that is above 1MB physical address?
When I send an extension request message to peers, but no response from peers.
I got Handshake and Extended Bitfield and Have Piece ok, but no extension data message.
This is my Golang code.
package main
import (
"bytes"
"crypto/rand"
"encoding/binary"
"fmt"
"github.com/IncSW/go-bencode"
"io"
"log"
"net"
"time"
)
func readBuffer(conn *net.TCPConn, size uint32) ([]byte, error) {
//temp := make([]byte, size)
//_, err := conn.Read(temp)
//if err != nil {
// return nil, fmt.Errorf("read %d bytes message failed: %v", size, err)
//}
//return temp, nil
buffer := bytes.NewBuffer(nil)
conn.SetReadDeadline(time.Now().Add(time.Second * 120))
_, err := io.CopyN(buffer, conn, int64(size))
if err != nil {
return nil, fmt.Errorf("read %d bytes message failed: %v", size, err)
}
return buffer.Bytes(), nil
}
func next(conn *net.TCPConn) ([]byte, error) {
buffer, err := readBuffer(conn, 4)
if nil != err {
return nil, err
}
buffer, err = readBuffer(conn, binary.BigEndian.Uint32(buffer))
if nil != err {
return nil, err
}
return buffer, nil
}
func getHandshake(infoHash []byte, nodeId []byte) []byte {
packet := []byte{19, 66, 105, 116, 84, 111, 114, 114, 101, 110, 116, 32, 112, 114, 111, 116, 111, 99, 111, 108, 0, 0, 0, 0, 0, 16, 0, 1}
packet = append(packet, infoHash...)
packet = append(packet, nodeId...)
return packet
}
// http://www.bittorrent.org/beps/bep_0009.html
// http://www.bittorrent.org/beps/bep_0010.html
func peerWire(addr string, infoHash []byte, nodeId []byte) {
dial, err := net.DialTimeout("tcp", addr, 10*time.Second)
if nil != err {
return
}
conn := dial.(*net.TCPConn)
conn.SetLinger(0)
defer conn.Close()
// handshake
handshake := getHandshake(infoHash, nodeId)
conn.Write(handshake)
handshakeRes := make([]byte, 68)
_, err = conn.Read(handshakeRes)
if !(bytes.Equal(handshake[:20], handshakeRes[:20]) && handshakeRes[25]&0x10 != 0) {
log.Println("invalid handshake response")
return
}
// extended handshake
// [length prefix][BitTorrent message ID][extended message ID]
extendedHandshake, _ := bencode.Marshal(map[string]interface{}{
"m": map[string]interface{}{"ut_metadata": 1},
})
extendedHandshake = append([]byte{20, 0}, extendedHandshake...)
size := make([]byte, 4)
extendedHandshake = append(size, extendedHandshake...)
conn.Write(extendedHandshake)
buffer, err := next(conn)
if nil != err {
log.Println(err.Error())
return
}
if 0 < len(buffer) {
msgUT, err := bencode.Unmarshal(buffer[2:])
if nil != err {
log.Println("error")
return
}
metadataSize, ok := msgUT.(map[string]interface{})["metadata_size"].(int64)
if !ok {
return
}
m, ok := msgUT.(map[string]interface{})["m"].(map[string]interface{})
if !ok {
return
}
utMetadata, ok := m["ut_metadata"].(int64)
if !ok {
return
}
numberOfPieces := metadataSize / 16384
if metadataSize%16384 != 0 {
numberOfPieces++
}
for i := 0; i < int(numberOfPieces); i++ {
packet, err := bencode.Marshal(map[string]interface{}{"msg_type":0, "piece":int(i)})
if nil != err {
log.Println(err)
}
packet = append([]byte{20, byte(utMetadata)}, packet...)
size := make([]byte, 4)
binary.BigEndian.PutUint32(size, uint32(len(packet)))
packet = append(size, packet...)
conn.Write(packet)
break
}
piece := make([]byte, 0)
for {
buffer, err := next(conn)
if nil != err {
log.Println(err.Error())
break
}
log.Println(buffer)
if 20 != buffer[0] {
continue
}
log.Println("buffer: ", buffer)
piece = append(piece, buffer...)
}
log.Println("index :", bytes.Index(piece, []byte("ee")))
}
}
func main() {
nodeId := make([]byte, 20)
rand.Read(nodeId)
infoHash := []byte{231, 130, 244, 163, 244, 122, 203, 232, 78, 218, 29, 116, 240, 232, 146, 236, 199, 72, 132, 254}
addr := "203.81.67.114:55254"
peerWire(addr, infoHash, nodeId)
}
I think the extension request message "[]byte{0, 0, 0, 27, 20, 2, 100, 53, 58, 112, 105, 101, 99, 101, 105, 48, 101, 56, 58, 109, 115, 103, 95, 116, 121, 112, 101, 105, 48, 101, 101}" format is correct.
WireShark Dump Data
From the pcap:
00000044 00 00 00 00 14 00 64 31 3a 6d 64 31 31 3a 75 74 ......d1 :md11:ut
00000054 5f 6d 65 74 61 64 61 74 61 69 31 65 65 65 _metadat ai1eee
You're sending 00 00 00 00 as the length for the extension handshake. That will be interpreted as a keepalive message and the rest as a message with length 14 00 64 31 and type 3a i.e. complete nonsense.
Complete pcap:
00000000 13 42 69 74 54 6f 72 72 65 6e 74 20 70 72 6f 74 .BitTorr ent prot
00000010 6f 63 6f 6c 00 00 00 00 00 10 00 01 e7 82 f4 a3 ocol.... ........
00000020 f4 7a cb e8 4e da 1d 74 f0 e8 92 ec c7 48 84 fe .z..N..t .....H..
00000030 0d 3a 6c 0f 88 e8 41 45 b9 96 b4 52 62 eb 33 cc .:l...AE ...Rb.3.
00000040 ca 73 8b bf .s..
00000000 13 42 69 74 54 6f 72 72 65 6e 74 20 70 72 6f 74 .BitTorr ent prot
00000010 6f 63 6f 6c 00 00 00 00 00 10 00 05 e7 82 f4 a3 ocol.... ........
00000020 f4 7a cb e8 4e da 1d 74 f0 e8 92 ec c7 48 84 fe .z..N..t .....H..
00000030 2d 55 54 33 35 34 53 2d 58 ae 73 ad 79 d9 8e d6 -UT354S- X.s.y...
00000040 bd be b0 5f 00 00 00 e6 14 00 64 31 3a 65 69 30 ..._.... ..d1:ei0
00000050 65 34 3a 69 70 76 34 34 3a cb 51 43 72 31 32 3a e4:ipv44 :.QCr12:
00000060 63 6f 6d 70 6c 65 74 65 5f 61 67 6f 69 complete _agoi
00000044 00 00 00 00 14 00 64 31 3a 6d 64 31 31 3a 75 74 ......d1 :md11:ut
00000054 5f 6d 65 74 61 64 61 74 61 69 31 65 65 65 _metadat ai1eee
0000006D 33 65 31 3a 6d 64 31 31 3a 75 70 6c 6f 61 64 5f 3e1:md11 :upload_
0000007D 6f 6e 6c 79 69 33 65 31 31 3a 6c 74 5f 64 6f 6e onlyi3e1 1:lt_don
0000008D 74 68 61 76 65 69 37 65 31 32 3a 75 74 5f 68 6f thavei7e 12:ut_ho
0000009D 6c 65 70 75 6e 63 68 69 34 65 31 31 3a 75 74 5f lepunchi 4e11:ut_
000000AD 6d 65 74 61 64 61 74 61 69 32 65 36 3a 75 74 5f metadata i2e6:ut_
000000BD 70 65 78 69 31 65 31 30 3a 75 74 5f 63 6f 6d 6d pexi1e10 :ut_comm
000000CD 65 6e 74 69 36 65 65 31 33 3a 6d 65 74 61 64 61 enti6ee1 3:metada
000000DD 74 61 5f 73 69 7a 65 69 38 38 38 32 65 31 3a 70 ta_sizei 8882e1:p
000000ED 69 35 35 32 35 34 65 34 3a 72 65 71 71 69 32 35 i55254e4 :reqqi25
000000FD 35 65 31 3a 76 31 35 3a ce bc 54 6f 72 72 65 6e 5e1:v15: ..Torren
0000010D 74 20 33 2e 35 2e 34 32 3a 79 70 69 33 31 34 30 t 3.5.42 :ypi3140
0000011D 38 65 36 3a 79 6f 75 72 69 70 34 3a 75 8b d0 19 8e6:your ip4:u...
0000012D 65 00 00 00 38 05 ff ef ff df f7 f7 ff ff ff ff e...8... ........
0000013D ff df ff ff df ff ff ff ef ff ff ee fe ff ff ff ........ ........
0000014D 6f ff ff 99 ff ff fd ff ff ff ff ff ff ff ef ff o....... ........
0000015D ff fe f7 ff ff fc ff bf ff ff bf ff c0 00 00 00 ........ ........
0000016D 05 04 00 00 00 5a 00 00 00 05 04 00 00 00 0b 00 .....Z.. ........
0000017D 00 00 05 04 00 00 00 e9 00 00 00 05 04 00 00 00 ........ ........
0000018D ea 00 00 00 05 04 00 00 01 64 00 00 00 05 04 00 ........ .d......
0000019D 00 01 5f 00 00 00 05 04 00 00 00 d3 00 00 00 05 .._..... ........
000001AD 04 00 00 01 7f 00 00 00 05 04 00 00 00 1a 00 00 ........ ........
000001BD 00 05 04 00 00 00 24 00 00 00 05 04 00 00 01 89 ......$. ........
000001CD 00 00 00 05 04 00 00 00 ee 00 00 00 05 04 00 00 ........ ........
000001DD 01 06 00 00 00 05 04 00 00 00 ed 00 00 00 05 04 ........ ........
000001ED 00 00 00 2c 00 00 00 05 04 00 00 00 93 00 00 00 ...,.... ........
000001FD 05 04 00 00 00 ab 00 00 00 05 04 00 00 00 d0 00 ........ ........
0000020D 00 00 05 04 00 00 00 b7 00 00 00 05 04 00 00 01 ........ ........
0000021D a1 00 00 00 05 04 00 00 00 72 00 00 00 05 04 00 ........ .r......
0000022D 00 01 43 00 00 00 05 04 00 00 01 7e 00 00 00 05 ..C..... ...~....
0000023D 04 00 00 00 af .....
00000062 00 00 00 1b 14 02 64 38 3a 6d 73 67 5f 74 79 70 ......d8 :msg_typ
00000072 65 69 30 65 35 3a 70 69 65 63 65 69 30 65 65 ei0e5:pi ecei0ee
00000242 13 42 69 74 54 6f 72 72 65 6e 74 20 70 72 6f 74 .BitTorr ent prot
00000252 6f 63 6f 6c 00 00 00 00 00 10 00 05 e7 82 f4 a3 ocol.... ........
00000262 f4 7a cb e8 4e da 1d 74 f0 e8 92 ec c7 48 84 fe .z..N..t .....H..
00000272 2d 55 54 33 35 34 53 2d 58 ae 73 ad 79 d9 8e d6 -UT354S- X.s.y...
00000282 bd be b0 5f 00 00 00 e6 14 00 64 31 3a 65 69 30 ..._.... ..d1:ei0
00000292 65 34 3a 69 70 76 34 34 3a cb 51 43 72 31 32 3a e4:ipv44 :.QCr12:
000002A2 63 6f 6d 70 6c 65 74 65 5f 61 67 6f 69 33 65 31 complete _agoi3e1
000002B2 3a 6d 64 31 31 3a 75 70 6c 6f 61 64 5f 6f 6e 6c :md11:up load_onl
000002C2 79 69 33 65 31 31 3a 6c 74 5f 64 6f 6e 74 68 61 yi3e11:l t_dontha
000002D2 76 65 69 37 65 31 32 3a 75 74 5f 68 6f 6c 65 70 vei7e12: ut_holep
000002E2 75 6e 63 68 69 34 65 31 31 3a 75 74 5f 6d 65 74 unchi4e1 1:ut_met
000002F2 61 64 61 74 61 69 32 65 36 3a 75 74 5f 70 65 78 adatai2e 6:ut_pex
00000302 69 31 65 31 30 3a 75 74 5f 63 6f 6d 6d 65 6e 74 i1e10:ut _comment
00000312 69 36 65 65 31 33 3a 6d 65 74 61 64 61 74 61 5f i6ee13:m etadata_
00000322 73 69 7a 65 69 38 38 38 32 65 31 3a 70 69 35 35 sizei888 2e1:pi55
00000332 32 35 34 65 34 3a 72 65 71 71 69 32 35 35 65 31 254e4:re qqi255e1
00000342 3a 76 31 35 3a ce bc 54 6f 72 72 65 6e 74 20 33 :v15:..T orrent 3
00000352 2e 35 2e 34 32 3a 79 70 69 33 31 34 30 38 65 36 .5.42:yp i31408e6
00000362 3a 79 6f 75 72 69 70 34 3a 75 8b d0 19 65 00 00 :yourip4 :u...e..
00000372 00 38 05 ff ef ff df f7 f7 ff ff ff ff ff df ff .8...... ........
00000382 ff df ff ff ff ef ff ff ee fe ff ff ff 6f ff ff ........ .....o..
00000392 99 ff ff fd ff ff ff ff ff ff ff ef ff ff fe f7 ........ ........
000003A2 ff ff fc ff bf ff ff bf ff c0 00 00 00 05 04 00 ........ ........
000003B2 00 00 5a 00 00 00 05 04 00 00 00 0b 00 00 00 05 ..Z..... ........
000003C2 04 00 00 00 e9 00 00 00 05 04 00 00 00 ea 00 00 ........ ........
000003D2 00 05 04 00 00 01 64 00 00 00 05 04 00 00 01 5f ......d. ......._
000003E2 00 00 00 05 04 00 00 00 d3 00 00 00 05 04 00 00 ........ ........
000003F2 01 7f 00 00 00 05 04 00 00 00 1a 00 00 00 05 04 ........ ........
00000402 00 00 00 24 00 00 00 05 04 00 00 01 89 00 00 00 ...$.... ........
00000412 05 04 00 00 00 ee 00 00 00 05 04 00 00 01 06 00 ........ ........
00000422 00 00 05 04 00 00 00 ed 00 00 00 05 04 00 00 00 ........ ........
00000432 2c 00 00 00 05 04 00 00 00 93 00 00 00 05 04 00 ,....... ........
00000442 00 00 ab 00 00 00 05 04 00 00 00 d0 00 00 00 05 ........ ........
00000452 04 00 00 00 b7 00 00 00 05 04 00 00 01 a1 00 00 ........ ........
00000462 00 05 04 00 00 00 72 00 00 00 05 04 00 00 01 43 ......r. .......C
00000472 00 00 00 05 04 00 00 01 7e 00 00 00 05 04 00 00 ........ ~.......
00000482 00 af 00 00 00 03 09 d7 d6 ........ .
I am writing some code to send electronic identification cards using ISO-7816:
If I send a "SELECT FILE" command:
INFO: Send command PC -> SAM: 00 a4 04 00 0f a0 00 00 00 18 43 4d 08 09 0a 0b 0c 00 00 00
INFO: Receive from SAM -> PC: 6F 62 84 0F A0 00 00 00 18 43 4D 08 09 0A 0B 0C 00 00 00 A5 4F 73 49 06 07 2A 86 48
86 FC 6B 01 60 0B 06 09 2A 86 48 86 FC 6B 02 02 02 63 09 06 07 2A 86 48 86 FC 6B 03
64 0B 06 09 2A 86 48 86 FC 6B 04 02 55 64 0B 06 09 2A 86 48 86 FC 6B 04 80 00 66 0C
06 0A 2B 06 01 04 01 2A 02 6E 01 03 9F 65 01 FF
After that, I send an "INITIALIZE UPDATE" command
-> 80 50 20 00 08 81 C3 21 A7 9D 7A DE 3E
And the response is
<- 69 82
[ERR] Smartcard::Iso::ApduError: ISO-7816 response APDU has error status 0x6982
I don't understand why I'm getting that response.
Well, 6982 means "access condition not fulfilled", depending on the how the card was created this could mean that that you need to verify with CHV or ADM key.