I have a requirement, where I need to parse a matroska file. Initial few bytes of file is given as below.
0x1a 0x45 0xdf 0xa3 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x23 0x42 0x86 0x81 0x01
0x42 0xf7 0x81 0x01 0x42 0xf2 0x81 0x04 0x42 0xf3 0x81 0x08 0x42 0x82 0x88 0x6d
0x61 0x74 0x72 0x6f 0x73 0x6b 0x61 0x42 0x87 0x81 0x04 0x42 0x85 0x81 0x02 0x18
0x53 0x80 0x67 0x01 0x00 0x00 0x00 0x00 0x33 0xdb 0x10 0x11 0x4d 0x9b 0x74 0x40
0x42 0xbf 0x84 0x11 0xac 0x83 0x8a 0x4d 0xbb 0x8b 0x53 0xab 0x84 0x15 0x49 0xa9
0x66 0x53 0xac 0x81 0xe5 0x4d 0xbb 0x8c 0x53 0xab 0x84 0x16 0x54 0xae 0x6b 0x53
0xac 0x82 0x01 0x56 0x4d 0xbb 0x8c 0x53 0xab 0x84 0x12 0x54 0xc3 0x67 0x53 0xac
0x82 0x11 0x5c 0x4d 0xbb 0x8d 0x53 0xab 0x84 0x1c 0x53 0xbb 0x6b 0x53 0xac 0x83
0x33 0xd9 0x1c 0xec 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x94 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
I am trying to parse this file. I have parsed first 59 bytes successfully. Now I am at 60th byte. From 6th byte bytes are 0x11 0x4d 0x9b 0x74 (shown in bold), so it means seekhead is starting.
I used mkvinfo to view parsed data. As per mkvinfo as shown below, seekhead starts at 59 which is fine.
Looks the first seek entry starts at 71. Now from 59th to 71st position what is there. This part I am not able to understand.
Can somebody please help me to understand this part.
You should parse the bytes like this† (refer to the Matroska specification for details):
0x11 0x4d 0x9b 0x74 (element ID: SeekHead)
0x40 0x42 (element size: 66)
0xbf (element ID: CRC-32)
0x84 (element size: 4)
0x11 0xac 0x83 0x8a (4-byte CRC-32 value)
0x4d 0xbb (element ID: Seek)
0x8b (element size: 11)
0x53 0xab (element ID: SeekID)
0x84 (element size: 4)
0x15 0x49 0xa9 0x66 (SeekID value; refers to Info element ID)
0x53 0xac (element ID: SeekPosition)
0x81 (element size: 1)
0xe5 (SeekPosition value: 229)
0x4d 0xbb (element ID: Seek)
0x8c (element size: 12)
0x53 0xab (element ID: SeekID)
0x84 (element size: 4)
0x16 0x54 0xae 0x6b (SeekID value; refers to Tracks element ID)
0x53 0xac (element ID: SeekPosition)
0x82 (element size: 2)
0x01 0x56 (SeekPosition value: 342)
0x4d 0xbb (element ID: Seek)
0x8c (element size: 12)
0x53 0xab (element ID: SeekID)
0x84 (element size: 4)
0x12 0x54 0xc3 0x67 (SeekID value; refers to Tags element ID)
0x53 0xac (element ID: SeekPosition)
0x82 (element size: 2)
0x11 0x5c (SeekPosition value: 4444)
0x4d 0xbb (element ID: Seek)
0x8d (element size: 13)
0x53 0xab (element ID: SeekID)
0x84 (element size: 4)
0x1c 0x53 0xbb 0x6b (SeekID value; refers to Cues element ID)
0x53 0xac (element ID: SeekPosition)
0x83 (element size: 3)
0x33 0xd9 0x1c (SeekPosition value: 3397916)
0xec (element ID: Void)
[I stopped parsing here]
A simplified ASCII graphic of the structure of these specific bytes is as follows:
+- SeekHead -------+
| CRC-32 |
| +- Seek--------+ |
| | SeekID | |
| | SeekPosition | |
| +--------------+ |
| +- Seek--------+ |
| | SeekID | |
| | SeekPosition | |
| +--------------+ |
| +- Seek--------+ |
| | SeekID | |
| | SeekPosition | |
| +--------------+ |
| +- Seek--------+ |
| | SeekID | |
| | SeekPosition | |
| +--------------+ |
+------------------+
Void
I've drawn the master elements (elements which contain other elements) as boxes.
To answer your specific question:
Looks the first seek entry starts at 71. Now from 59th to 71st position what is there. This part I am not able to understand.
The SeekHead begins at byte 59. It's size begins 4 bytes later at byte 63. After that, a CRC-32 element begins at byte 65. After that, at byte 71, the first Seek element is found.
†I've just parsed this mentally by hand; hopefully I haven't made any errors or typos.
Related
Following up with How do I check the size of a Go project?
The conclusion was:
in order to get a true sense of how much extra weight importing certain packages, one has to look at all of the pkg's sub-dependencies as well.
That's totally understandable. My question is,
Is there anyway that I can know how much space each component is taking in my compiled binary, the Go runtime, the dependencies and sub-dependencies packages, and my own code.
I vaguely remember reading something like this before (when go enhanced its linker maybe).
If there has never been such discussion before, then is there any way the go or even c linker can look into the my compiled binary, and reveal something that I can further parse myself?
The binary will contain debug symbols which we can use to figure out how many space each package takes up.
I wrote a basic program to do this since I don't know of any tool that does this:
package main
import (
"debug/elf"
"fmt"
"os"
"runtime"
"sort"
"strings"
"github.com/go-delve/delve/pkg/proc"
)
func main() {
// Use delve to decode the DWARF section
binInfo := proc.NewBinaryInfo(runtime.GOOS, runtime.GOARCH)
err := binInfo.AddImage(os.Args[1], 0)
if err != nil {
panic(err)
}
// Make a list of unique packages
pkgs := make([]string, 0, len(binInfo.PackageMap))
for _, fullPkgs := range binInfo.PackageMap {
for _, fullPkg := range fullPkgs {
exists := false
for _, pkg := range pkgs {
if fullPkg == pkg {
exists = true
break
}
}
if !exists {
pkgs = append(pkgs, fullPkg)
}
}
}
// Sort them for a nice output
sort.Strings(pkgs)
// Parse the ELF file ourselfs
elfFile, err := elf.Open(os.Args[1])
if err != nil {
panic(err)
}
// Get the symbol table
symbols, err := elfFile.Symbols()
if err != nil {
panic(err)
}
usage := make(map[string]map[string]int)
for _, sym := range symbols {
if sym.Section == elf.SHN_UNDEF || sym.Section >= elf.SectionIndex(len(elfFile.Sections)) {
continue
}
sectionName := elfFile.Sections[sym.Section].Name
symPkg := ""
for _, pkg := range pkgs {
if strings.HasPrefix(sym.Name, pkg) {
symPkg = pkg
break
}
}
// Symbol doesn't belong to a known package
if symPkg == "" {
continue
}
pkgStats := usage[symPkg]
if pkgStats == nil {
pkgStats = make(map[string]int)
}
pkgStats[sectionName] += int(sym.Size)
usage[symPkg] = pkgStats
}
for _, pkg := range pkgs {
sections, exists := usage[pkg]
if !exists {
continue
}
fmt.Printf("%s:\n", pkg)
for section, size := range sections {
fmt.Printf("%15s: %8d bytes\n", section, size)
}
fmt.Println()
}
}
Now the actual space used is divided over multiple section(.text for code, .bss for zero initialized data, .data for global vars, ect.). This example lists the size per section, but you can modify the code to get the total if that is what you prefer.
Here is the outputs it generates from its own binary:
bufio:
.text: 12733 bytes
.noptrdata: 64 bytes
.bss: 176 bytes
.rodata: 72 bytes
bytes:
.bss: 48 bytes
.rodata: 64 bytes
.text: 12617 bytes
.noptrdata: 320 bytes
compress/flate:
.text: 20385 bytes
.noptrdata: 248 bytes
.bss: 2112 bytes
.noptrbss: 12 bytes
.rodata: 48 bytes
compress/zlib:
.text: 4138 bytes
.noptrdata: 96 bytes
.bss: 48 bytes
container/list:
.text: 4016 bytes
context:
.text: 387 bytes
.noptrdata: 72 bytes
.bss: 40 bytes
crypto:
.text: 20982 bytes
.noptrdata: 416 bytes
.bss: 96 bytes
.rodata: 58 bytes
.noptrbss: 3 bytes
debug/dwarf:
.rodata: 1088 bytes
.text: 113878 bytes
.noptrdata: 247 bytes
.bss: 64 bytes
debug/elf:
.rodata: 168 bytes
.text: 36557 bytes
.noptrdata: 112 bytes
.data: 5160 bytes
.bss: 16 bytes
debug/macho:
.text: 22980 bytes
.noptrdata: 96 bytes
.data: 456 bytes
.rodata: 80 bytes
debug/pe:
.text: 26004 bytes
.noptrdata: 96 bytes
.rodata: 288 bytes
encoding/base64:
.bss: 32 bytes
.rodata: 48 bytes
.text: 846 bytes
.noptrdata: 56 bytes
encoding/binary:
.text: 27108 bytes
.noptrdata: 72 bytes
.bss: 56 bytes
.rodata: 136 bytes
encoding/hex:
.bss: 16 bytes
.text: 288 bytes
.noptrdata: 64 bytes
encoding/json:
.rodata: 108 bytes
.text: 2930 bytes
.noptrdata: 128 bytes
.bss: 80 bytes
errors:
.rodata: 48 bytes
.text: 744 bytes
.noptrdata: 40 bytes
.bss: 16 bytes
fmt:
.text: 72010 bytes
.noptrdata: 136 bytes
.data: 104 bytes
.bss: 32 bytes
.rodata: 720 bytes
github.com/cilium/ebpf:
.text: 170860 bytes
.noptrdata: 1405 bytes
.bss: 608 bytes
.rodata: 3971 bytes
.data: 16 bytes
.noptrbss: 8 bytes
github.com/go-delve/delve/pkg/dwarf/frame:
.text: 18304 bytes
.noptrdata: 80 bytes
.bss: 8 bytes
.rodata: 211 bytes
github.com/go-delve/delve/pkg/dwarf/godwarf:
.text: 40431 bytes
.noptrdata: 144 bytes
.rodata: 352 bytes
github.com/go-delve/delve/pkg/dwarf/line:
.bss: 48 bytes
.rodata: 160 bytes
.text: 24069 bytes
.noptrdata: 96 bytes
github.com/go-delve/delve/pkg/dwarf/loclist:
.noptrdata: 64 bytes
.rodata: 64 bytes
.text: 4538 bytes
github.com/go-delve/delve/pkg/dwarf/op:
.text: 31142 bytes
.noptrdata: 80 bytes
.bss: 72 bytes
.rodata: 5313 bytes
github.com/go-delve/delve/pkg/dwarf/reader:
.noptrdata: 72 bytes
.bss: 16 bytes
.rodata: 24 bytes
.text: 8037 bytes
github.com/go-delve/delve/pkg/dwarf/regnum:
.bss: 40 bytes
.rodata: 2760 bytes
.text: 3943 bytes
.noptrdata: 48 bytes
github.com/go-delve/delve/pkg/dwarf/util:
.text: 4028 bytes
.noptrdata: 64 bytes
.rodata: 96 bytes
github.com/go-delve/delve/pkg/elfwriter:
.text: 3394 bytes
.noptrdata: 48 bytes
.rodata: 48 bytes
github.com/go-delve/delve/pkg/goversion:
.noptrdata: 104 bytes
.bss: 64 bytes
.rodata: 160 bytes
.text: 4415 bytes
github.com/go-delve/delve/pkg/logflags:
.bss: 32 bytes
.rodata: 40 bytes
.text: 2610 bytes
.noptrdata: 136 bytes
.noptrbss: 3 bytes
github.com/go-delve/delve/pkg/proc:
.text: 432477 bytes
.noptrdata: 718 bytes
.data: 1448 bytes
.bss: 592 bytes
.rodata: 10106 bytes
github.com/go-delve/delve/pkg/version:
.text: 1509 bytes
.noptrdata: 72 bytes
.data: 112 bytes
.rodata: 40 bytes
github.com/hashicorp/golang-lru/simplelru:
.text: 3911 bytes
.noptrdata: 32 bytes
.rodata: 160 bytes
github.com/sirupsen/logrus:
.noptrbss: 20 bytes
.rodata: 696 bytes
.text: 40175 bytes
.noptrdata: 204 bytes
.data: 64 bytes
.bss: 56 bytes
go/ast:
.text: 24407 bytes
.noptrdata: 104 bytes
.data: 112 bytes
.rodata: 120 bytes
go/constant:
.bss: 8 bytes
.rodata: 824 bytes
.text: 33910 bytes
.noptrdata: 88 bytes
go/parser:
.rodata: 1808 bytes
.text: 78751 bytes
.noptrdata: 136 bytes
.bss: 32 bytes
go/printer:
.text: 77202 bytes
.noptrdata: 113 bytes
.data: 24 bytes
.rodata: 1504 bytes
go/scanner:
.rodata: 240 bytes
.text: 18594 bytes
.noptrdata: 93 bytes
.data: 24 bytes
go/token:
.noptrdata: 72 bytes
.data: 1376 bytes
.bss: 8 bytes
.rodata: 192 bytes
.text: 7154 bytes
golang.org/x/arch/arm64/arm64asm:
.rodata: 856 bytes
.text: 116428 bytes
.noptrdata: 80 bytes
.bss: 80 bytes
.data: 46128 bytes
golang.org/x/arch/x86/x86asm:
.noptrdata: 29125 bytes
.bss: 112 bytes
.data: 20928 bytes
.rodata: 1252 bytes
.text: 76721 bytes
golang.org/x/sys/unix:
.text: 1800 bytes
.noptrdata: 128 bytes
.rodata: 70 bytes
.data: 80 bytes
hash/adler32:
.text: 1013 bytes
.noptrdata: 40 bytes
internal/bytealg:
.rodata: 56 bytes
.noptrbss: 8 bytes
.text: 1462 bytes
.noptrdata: 32 bytes
internal/cpu:
.rodata: 500 bytes
.noptrbss: 416 bytes
.noptrdata: 8 bytes
.bss: 24 bytes
.text: 3017 bytes
internal/fmtsort:
.text: 7443 bytes
.noptrdata: 40 bytes
.rodata: 40 bytes
internal/oserror:
.text: 500 bytes
.noptrdata: 40 bytes
.bss: 80 bytes
internal/poll:
.text: 31565 bytes
.rodata: 192 bytes
.noptrdata: 112 bytes
.data: 96 bytes
.bss: 64 bytes
.noptrbss: 12 bytes
internal/reflectlite:
.text: 13761 bytes
.noptrdata: 32 bytes
.data: 456 bytes
.bss: 24 bytes
.rodata: 496 bytes
internal/syscall/unix:
.rodata: 72 bytes
.text: 708 bytes
.noptrdata: 40 bytes
.noptrbss: 4 bytes
internal/testlog:
.text: 827 bytes
.noptrdata: 32 bytes
.noptrbss: 12 bytes
.bss: 16 bytes
.rodata: 72 bytes
io:
.noptrdata: 240 bytes
.bss: 272 bytes
.data: 56 bytes
.noptrbss: 0 bytes
.rodata: 128 bytes
.text: 10824 bytes
log:
.text: 188 bytes
.noptrdata: 80 bytes
.bss: 8 bytes
main:
.text: 3002 bytes
.noptrdata: 80 bytes
.rodata: 104 bytes
math:
.data: 136 bytes
.bss: 2672 bytes
.text: 184385 bytes
.noptrdata: 10211 bytes
.rodata: 2076 bytes
.noptrbss: 2 bytes
net:
.text: 24417 bytes
.noptrdata: 236 bytes
.data: 240 bytes
.bss: 584 bytes
.noptrbss: 16 bytes
.rodata: 48 bytes
os:
.bss: 264 bytes
.data: 32 bytes
.rodata: 352 bytes
.text: 46276 bytes
.noptrdata: 296 bytes
.noptrbss: 1 bytes
path:
.text: 9378 bytes
.noptrdata: 136 bytes
.bss: 48 bytes
.rodata: 48 bytes
reflect:
.noptrbss: 1 bytes
.text: 97417 bytes
.noptrdata: 72 bytes
.rodata: 1728 bytes
.data: 456 bytes
.bss: 160 bytes
regexp:
.rodata: 968 bytes
.text: 126451 bytes
.noptrdata: 558 bytes
.bss: 296 bytes
.noptrbss: 16 bytes
.data: 816 bytes
runtime:
.noptrbss: 20487 bytes
.data: 8520 bytes
.bss: 184836 bytes
.tbss: 8 bytes
.typelink: 9020 bytes
.gopclntab: 0 bytes
.text: 408713 bytes
.noptrdata: 4347 bytes
.rodata: 23102 bytes
.itablink: 2952 bytes
sort:
.text: 13055 bytes
.noptrdata: 32 bytes
.data: 16 bytes
.rodata: 24 bytes
strconv:
.text: 45928 bytes
.noptrdata: 17015 bytes
.data: 1680 bytes
.bss: 32 bytes
.rodata: 144 bytes
strings:
.text: 21070 bytes
.noptrdata: 320 bytes
.rodata: 168 bytes
sync:
.rodata: 476 bytes
.noptrdata: 56 bytes
.bss: 56 bytes
.noptrbss: 8 bytes
.text: 14288 bytes
syscall:
.noptrdata: 127 bytes
.rodata: 978 bytes
.noptrbss: 76 bytes
.bss: 264 bytes
.data: 2720 bytes
.text: 33728 bytes
text/tabwriter:
.data: 96 bytes
.rodata: 88 bytes
.text: 8002 bytes
.noptrdata: 46 bytes
text/template:
.text: 166284 bytes
.noptrdata: 316 bytes
.noptrbss: 8 bytes
.bss: 176 bytes
.data: 376 bytes
.rodata: 3152 bytes
time:
.text: 83290 bytes
.noptrdata: 164 bytes
.data: 912 bytes
.bss: 208 bytes
.noptrbss: 20 bytes
.rodata: 832 bytes
unicode:
.noptrdata: 50398 bytes
.data: 15248 bytes
.bss: 40 bytes
.noptrbss: 0 bytes
.text: 27198 bytes
Note this program isn't perfect, it only works on Linux/Mac since it relies on ELF. I am sure you can do a similar thing for Windows PE files, but that would have taken me to much time.
Also this program ignores some parts of the go runtime, but I am guessing that is not the most important to you.
You can run nm to get sizes of all objects in the binary.
Example: nm -S /usr/local/go/bin/gofmt. Second column is a size.
0000000000468700 000000000000011c T unicode/utf8.DecodeLastRuneInString
0000000000468240 00000000000001a6 T unicode/utf8.DecodeRune
0000000000468400 00000000000001a6 T unicode/utf8.DecodeRuneInString
0000000000468820 0000000000000157 T unicode/utf8.EncodeRune
To create assembly code I'm calling the mipsel-openwrt-linux-uclibc-gcc compiler (Linaro GCC 4.8-2014.04 r49389) with flag -S.
This produces assembly code looking like this:
.section .mdebug.abi32
.previous
.gnu_attribute 4, 3
.abicalls
.option pic0
.text
$Ltext0:
.cfi_sections .debug_frame
.globl Version
.section .rodata.str1.4,"aMS",#progbits,1
.align 2
$LC0:
.ascii "3.3\000"
.data
.align 2
.type Version, #object
.size Version, 4
Version:
.word $LC0
.text
$Letext0:
.file 1 "version.c"
.section .debug_info,"",#progbits
$Ldebug_info0:
.4byte 0x3d
.2byte 0x4
.4byte $Ldebug_abbrev0
.byte 0x4
.uleb128 0x1
.4byte $LASF0
.byte 0x1
.4byte $LASF1
.4byte $LASF2
.4byte $Ldebug_line0
.uleb128 0x2
.4byte $LASF3
.byte 0x1
.byte 0x2
.4byte 0x2e
.uleb128 0x5
.byte 0x3
.4byte Version
.uleb128 0x3
.byte 0x4
.4byte 0x34
.uleb128 0x4
.4byte 0x39
.uleb128 0x5
.byte 0x1
.byte 0x6
.4byte $LASF4
.byte 0
.section .debug_abbrev,"",#progbits
$Ldebug_abbrev0:
.uleb128 0x1
.uleb128 0x11
.byte 0x1
---- I cutted here ----
.uleb128 0xe
.byte 0
.byte 0
.byte 0
.section .debug_aranges,"",#progbits
.4byte 0x14
.2byte 0x2
.4byte $Ldebug_info0
.byte 0x4
.byte 0
.2byte 0
.2byte 0
.4byte 0
.4byte 0
.section .debug_line,"",#progbits
$Ldebug_line0:
.section .debug_str,"MS",#progbits,1
$LASF2:
.ascii "/home/lvr/Src/openwrt/build_dir/target-mipsel_mips32_uCl"
.ascii "ibc-0.9.33.2/diffutils-3.3/src\000"
$LASF0:
.ascii "GNU C 4.8.3 -mno-branch-likely -mips32 -mtune=mips32 -ms"
.ascii "oft-float -mllsc -mplt -mno-shared -g -Os -std=c99 -fno-"
.ascii "caller-saves -fhonour-copts\000"
$LASF3:
.ascii "Version\000"
$LASF4:
.ascii "char\000"
$LASF1:
.ascii "version.c\000"
.ident "GCC: (OpenWrt/Linaro GCC 4.8-2014.04 r49389) 4.8.3"
.section .note.GNU-stack,"",#progbits
This doesn't look like AT&T nor Intel syntax to me. To produce more familiar syntax I've tried the -masm=intel flag, but same effect..
My first thougt was the produced ASM code is dedicated to the fixed word width of mips,
but any ideas how to generate AT&T or Intel syntax via mipsel-openwrt-linux-uclibc-gcc?
Thanks for any hints!
"What AT&T and Intel syntax have to do with MIPS?" - Nothing directly, I've tagged it that way as tag 'mipsel-openwrt-linux-uclibc-gcc' was not available (sry, maybe bad style).
But thanks Margaret your comment directed me to compile some more .c files leading to the expected AT&T syntax :) - f.e.:
.section .mdebug.abi32
.previous
.gnu_attribute 4, 3
.abicalls
.option pic0
.text
$Ltext0:
.cfi_sections .debug_frame
.align 2
$LFB16 = .
.file 1 "io.c"
.loc 1 474 0
.cfi_startproc
.set nomips16
.ent prepare_text
.type prepare_text, #function
prepare_text:
.frame $sp,48,$31 # vars= 0, regs= 5/0, args= 16, gp= 8
.mask 0x800f0000,-4
.fmask 0x00000000,0
.set noreorder
.set nomacro
$LVL0 = .
addiu $sp,$sp,-48
.cfi_def_cfa_offset 48
sw $17,32($sp)
sw $31,44($sp)
sw $19,40($sp)
sw $18,36($sp)
sw $16,28($sp)
.cfi_offset 17, -16
.cfi_offset 31, -4
.cfi_offset 19, -8
.cfi_offset 18, -12
--- CUT ---
$LASF16:
.ascii "__ino64_t\000"
$LASF86:
.ascii "changes\000"
$LASF66:
.ascii "__ctype_touplow_t\000"
$LASF200:
.ascii "memcmp\000"
$LASF118:
.ascii "equivs\000"
$LASF139:
.ascii "file_size\000"
.ident "GCC: (OpenWrt/Linaro GCC 4.8-2014.04 r49389) 4.8.3"
.section .note.GNU-stack,"",#progbits
How can I calculate heap chunk size from raw bytes read from memory.
I tried below thing.
0:001> !heap
Index Address Name Debugging options enabled
1: 00500000
2: 00280000
3: 008f0000
4: 00ab0000
5: 00cc0000
0:001> !heap -a 00500000
..
..
Heap entries for Segment00 in Heap 00500000
address: psize . size flags state (requested size)
00500000: 00000 . 00588 [101] - busy (587)
00500588: 00588 . 00240 [101] - busy (23f)
005007c8: 00240 . 00020 [101] - busy (18)
005007e8: 00020 . 00ca0 [101] - busy (c94)
..
..
!heap -a 00500000 shows that size of first chunk is 588 bytes.
If we dump the chunk header using dt _HEAP_ENTRY, it somehow shows size is 0x3822
0:001> dt _HEAP_ENTRY 00500000
ntdll!_HEAP_ENTRY
+0x000 Size : 0x3822
+0x002 Flags : 0xfc ''
+0x003 SmallTagIndex : 0xbb ''
+0x000 SubSegmentCode : 0xbbfc3822 Void
+0x004 PreviousSize : 0x1849
+0x006 SegmentOffset : 0 ''
+0x006 LFHFlags : 0 ''
+0x007 UnusedBytes : 0x1 ''
+0x000 FunctionIndex : 0x3822
+0x002 ContextValue : 0xbbfc
+0x000 InterceptorValue : 0xbbfc3822
+0x004 UnusedBytesLength : 0x1849
+0x006 EntryOffset : 0 ''
+0x007 ExtendedBlockSignature : 0x1 ''
+0x000 Code1 : 0xbbfc3822
+0x004 Code2 : 0x1849
+0x006 Code3 : 0 ''
+0x007 Code4 : 0x1 ''
+0x000 AgregateCode : 0x01001849`bbfc3822
When I dump the address 0x00500000 I find first two bytes are 22 and 38.
00500000 22 38 fc bb 49 18 00 01 ee ff ee ff 00 00 00 00 a8 00 "8..I.............
00500012 50 00 a8 00 50 00 00 00 50 00 00 00 50 00 00 01 00 00 P...P...P...P.....
00500024 88 05 50 00 00 00 60 00 cf 00 00 00 01 00 00 00 00 00 ..P...`...........
00500036 00 00 f0 0f 53 00 f0 0f 53 00 02 00 00 00 00 00 00 00 ....S...S.........
00500048 00 00 00 00 00 00 10 00 93 38 fd 0b 49 18 00 00 17 ff .........8..I.....
0050005a bb 44 00 00 00 00 00 fe 00 00 ff ee ff ee 00 00 10 00 .D................
0050006c 00 20 00 00 00 08 00 00 00 20 00 00 2e 04 00 00 ff ef . ....... ........
0050007e fd 7f 01 00 38 01 00 00 00 00 00 00 00 00 00 00 00 00 ....8.............
00500090 e8 0f 53 00 e8 0f 53 00 0f 00 00 00 f8 ff ff ff a0 00 ..S...S...........
005000a2 50 00 a0 00 50 00 10 00 50 00 10 00 50 00 00 00 00 00 P...P...P...P.....
My question is how does 22 and 38 (or 0x3822) becomes 0x588
Summary: heap entries are now encoded, the key is in the heap itself.
Let's say I have a heap at 0x00d60000:
0:000> !heap -a 00d60000
Index Address Name Debugging options enabled
2: 00d60000
Segment at 00d60000 to 00d70000 (00001000 bytes committed)
Flags: 40000061
ForceFlags: 40000061
Granularity: 8 bytes
Segment Reserve: 00100000
Segment Commit: 00002000
DeCommit Block Thres: 00000200
DeCommit Total Thres: 00002000
Total Free Size: 00000149
Max. Allocation Size: 7ffdefff
Lock Variable at: 00000000
Next TagIndex: 0000
Maximum TagIndex: 0000
Tag Entries: 00000000
PsuedoTag Entries: 00000000
Virtual Alloc List: 00d6009c
Uncommitted ranges: 00d6008c
00d61000: 0000f000 (61440 bytes)
FreeList[ 00 ] at 00d600c0: 00d605a0 . 00d605a0
00d60598: 00118 . 00a48 [104] - free
Segment00 at 00d60000:
Flags: 00000000
Base: 00d60000
First Entry: 00d60480
Last Entry: 00d70000
Total Pages: 00000010
Total UnCommit: 0000000f
Largest UnCommit:00000000
UnCommitted Ranges: (1)
Heap entries for Segment00 in Heap 00d60000
address: psize . size flags state (requested size)
00d60000: 00000 . 00480 [101] - busy (47f)
00d60480: 00480 . 00118 [107] - busy (100), tail fill
00d60598: 00118 . 00a48 [104] free fill
00d60fe0: 00a48 . 00020 [111] - busy (1d)
00d61000: 0000f000 - uncommitted bytes.
There's a busy block at 0x00d60480: its allocated size is 0x118 (the size of the previous block is 0x480).
If we dump this block we can see it's encoded:
0:000> dt _heap_entry 00d60480
ntdll!_HEAP_ENTRY
+0x000 Size : 0x7387
+0x002 Flags : 0xf5 ''
+0x003 SmallTagIndex : 0x64 'd'
+0x000 SubSegmentCode : 0x64f57387
+0x004 PreviousSize : 0xb95d
+0x006 SegmentOffset : 0 ''
+0x006 LFHFlags : 0 ''
+0x007 UnusedBytes : 0x18 ''
+0x000 FunctionIndex : 0x7387
+0x002 ContextValue : 0x64f5
+0x000 InterceptorValue : 0x64f57387
+0x004 UnusedBytesLength : 0xb95d
+0x006 EntryOffset : 0 ''
+0x007 ExtendedBlockSignature : 0x18 ''
+0x000 Code1 : 0x64f57387
+0x004 Code2 : 0xb95d
+0x006 Code3 : 0 ''
+0x007 Code4 : 0x18 ''
+0x004 Code234 : 0x1800b95d
+0x000 AgregateCode : 0x1800b95d`64f57387
Back to the heap, pay a particular attention to the field named "Encoding " (at offset 0x50):
0:000> dt _heap encoding
ntdll!_HEAP
+0x050 Encoding : _HEAP_ENTRY
Dumping the whole _HEAP structure:
0:000> dt _heap 00d60000
ntdll!_HEAP
+0x000 Entry : _HEAP_ENTRY
+0x008 SegmentSignature : 0xffeeffee
+0x00c SegmentFlags : 0
+0x010 SegmentListEntry : _LIST_ENTRY [ 0xd600a4 - 0xd600a4 ]
+0x018 Heap : 0x00d60000 _HEAP
+0x01c BaseAddress : 0x00d60000 Void
+0x020 NumberOfPages : 0x10
+0x024 FirstEntry : 0x00d60480 _HEAP_ENTRY
+0x028 LastValidEntry : 0x00d70000 _HEAP_ENTRY
+0x02c NumberOfUnCommittedPages : 0xf
+0x030 NumberOfUnCommittedRanges : 1
+0x034 SegmentAllocatorBackTraceIndex : 0
+0x036 Reserved : 0
+0x038 UCRSegmentList : _LIST_ENTRY [ 0xd60ff0 - 0xd60ff0 ]
+0x040 Flags : 0x40000061
+0x044 ForceFlags : 0x40000061
+0x048 CompatibilityFlags : 0
+0x04c EncodeFlagMask : 0x100000
+0x050 Encoding : _HEAP_ENTRY
+0x058 Interceptor : 0
+0x05c VirtualMemoryThreshold : 0xfe00
+0x060 Signature : 0xeeffeeff
+0x064 SegmentReserve : 0x100000
+0x068 SegmentCommit : 0x2000
+0x06c DeCommitFreeBlockThreshold : 0x200
+0x070 DeCommitTotalFreeThreshold : 0x2000
+0x074 TotalFreeSize : 0x149
+0x078 MaximumAllocationSize : 0x7ffdefff
+0x07c ProcessHeapsListIndex : 2
+0x07e HeaderValidateLength : 0x248
+0x080 HeaderValidateCopy : (null)
+0x084 NextAvailableTagIndex : 0
+0x086 MaximumTagIndex : 0
+0x088 TagEntries : (null)
+0x08c UCRList : _LIST_ENTRY [ 0xd60fe8 - 0xd60fe8 ]
+0x094 AlignRound : 0x17
+0x098 AlignMask : 0xfffffff8
+0x09c VirtualAllocdBlocks : _LIST_ENTRY [ 0xd6009c - 0xd6009c ]
+0x0a4 SegmentList : _LIST_ENTRY [ 0xd60010 - 0xd60010 ]
+0x0ac AllocatorBackTraceIndex : 0
+0x0b0 NonDedicatedListLength : 0
+0x0b4 BlocksIndex : 0x00d60248 Void
+0x0b8 UCRIndex : (null)
+0x0bc PseudoTagEntries : (null)
+0x0c0 FreeLists : _LIST_ENTRY [ 0xd605a0 - 0xd605a0 ]
+0x0c8 LockVariable : (null)
+0x0cc CommitRoutine : 0x7944d754 long +7944d754
+0x0d0 FrontEndHeap : (null)
+0x0d4 FrontHeapLockCount : 0
+0x0d6 FrontEndHeapType : 0 ''
+0x0d7 RequestedFrontEndHeapType : 0 ''
+0x0d8 FrontEndHeapUsageData : (null)
+0x0dc FrontEndHeapMaximumIndex : 0
+0x0de FrontEndHeapStatusBitmap : [257] ""
+0x1e0 Counters : _HEAP_COUNTERS
+0x23c TuningParameters : _HEAP_TUNING_PARAMETERS
Dumping the encoding field as two DWORDs:
0:000> dd 00d60000 + 0x50 L2
00d60050 40f273a4 0000b9cd
Now dumping the heap entry as two DWORDs:
0:000> dd 00d60480 L2
00d60480 64f57387 1800b95d
Let's XOR them:
0:000> ? 40f273a4 ^ 64f57387
Evaluate expression: 604438563 = 24070023
0:000> ? 0000b9cd ^ 1800b95d
Evaluate expression: 402653328 = 18000090
Now just writing a fake _HEAP_ENTRY so we can 'dt' it:
0:000> ed 00d604b0
00d604b0 00000000 24070023
24070023
00d604b4 00000000 18000090
18000090
00d604b8 00000000
0:000> dt _HEAP_ENTRY 00d604b0
ntdll!_HEAP_ENTRY
+0x000 Size : 0x23
+0x002 Flags : 0x7 ''
+0x003 SmallTagIndex : 0x24 '$'
+0x000 SubSegmentCode : 0x24070023
+0x004 PreviousSize : 0x90
+0x006 SegmentOffset : 0 ''
+0x006 LFHFlags : 0 ''
+0x007 UnusedBytes : 0x18 ''
+0x000 FunctionIndex : 0x23
+0x002 ContextValue : 0x2407
+0x000 InterceptorValue : 0x24070023
+0x004 UnusedBytesLength : 0x90
+0x006 EntryOffset : 0 ''
+0x007 ExtendedBlockSignature : 0x18 ''
+0x000 Code1 : 0x24070023
+0x004 Code2 : 0x90
+0x006 Code3 : 0 ''
+0x007 Code4 : 0x18 ''
+0x004 Code234 : 0x18000090
+0x000 AgregateCode : 0x18000090`24070023
Size field is 0x23, granularity is 8 bytes (as reported by the !heap -a command output). The real size of the block is the Size field value multiplied by the granularity, so:
0:000> ? 23 * 8
Evaluate expression: 280 = 00000118
It also works for the size of the previous block (reported to be 0x480):
0:000> ? 0x90 * 8
Evaluate expression: 11552 = 00000480
We found the same sizes.
Granularity
Granularity (as given by the !heap -a command output) is not indicated by a specific field, it's just the size of a HEAP_ENTRY structure:
8 bytes on x86 systems (or WOW64):
0:000> ?? sizeof(_HEAP_ENTRY)
unsigned int64 8
16 bytes on x64 systems:
0:000> ?? sizeof(_HEAP_ENTRY)
unsigned int64 0x10
Form Vista and later, the heap entries are scrambled so it’s a hard task
to do any calculations.
Check this link read about randomization.
The DT command are therefore unable do display any sensible information at all.
Take a look at the offsets:
0:001> dt _HEAP_ENTRY
+0x000 Size
+0x000 FunctionIndex
+0x000 InterceptorValue
+0x000 AgregateCode
A lot of elements with same offset, hence same memory.
Also observe your
+0x004 PreviousSize : 0x1849
Does not correspond with the psize of 0000 from !heap –a.
On Win XP and earlier your technique was possible, but here the
_HEAP_ENTRY-> Size
was number of heap blocks, usually of 8 bytes.
Edit:
I’m not aware of any manual method to decode the heap entry, but I guess it’s possible.
I have used the !heap –i command to do it for me.
First:
!heap –i <heap> , in your case !heap –i 00500000
Then
!heap –I <heap entry> , in your case !heap –I 00500588 (for second entry)
Sample:
address: psize . size flags state (requested size)
00240000: 00000 . 00588 [101] - busy (587)
00240588: 00588 . 00240 [101] - busy (23f)
....
0:000> !heap -i 00240000
Heap context set to the heap 0x00240000
0:000> !heap -i 00240588
Detailed information for block entry 00240588
Assumed heap : 0x00240000 (Use !heap -i NewHeapHandle to change)
Header content : 0x32343AD9 0x0100B0F1 (decoded : 0x49010048 0x010000B1)
Owning segment : 0x00240000 (offset 0)
Block flags : 0x1 (busy )
Total block size : 0x48 units (0x240 bytes)
Requested size : 0x23f bytes (unused 0x1 bytes)
Previous block size: 0xb1 units (0x588 bytes)
Block CRC : OK - 0x49
Previous block : 0x00240000
Next block : 0x002407c8
See also : this link
I use the sample code to read from MIFARE Ultralight and write to MIFARE Classic, with the definition in .h file:
#define PN532_RESPONSE_INDATAEXCHANGE (0x41)
#define MIFARE_CMD_WRITE (0xA0)
but when I run the code below:
/**************************************************************************/
uint8_t PN532::mifareultralight_WritePage (uint8_t page, uint8_t *buffer1)
{
/* Prepare the first command */
pn532_packetbuffer[0] = PN532_COMMAND_INDATAEXCHANGE;
pn532_packetbuffer[1] = 1; /* Card number */
pn532_packetbuffer[2] = MIFARE_CMD_WRITE; /* Mifare Write command = 0xA0 */
pn532_packetbuffer[3] = page; /* Page Number (0..63 in most cases) */
memcpy (pn532_packetbuffer + 4, buffer1, 4); /* Data Payload */
/* Send the command */
if (HAL(writeCommand)(pn532_packetbuffer, 8)) {
Serial.println(F("Go here 1"));
return 0;
}
Serial.println(F("Go here 2"));
/* Read the response packet */
return (0 < HAL(readResponse)(pn532_packetbuffer, sizeof(pn532_packetbuffer)));
}
The result would be like this:
Scan a NFC tag
write: 4A 1 0
read: 4B 1 1 0 44 0 7 4 C1 37 CA 2C 2C 80
ATQA: 0x 44SAK: 0x 0
Writing Mifare Ultralight
write: 40 1 30 4
read: 41 0 2 0 0 10 0 6 1 10 11 FF 0 0 0 0 0 0
write: 40 1 30 3
read: 41 0 0 0 0 0 2 0 0 10 0 6 1 10 11 FF 0 0
Tag capacity 0 bytes
write: 40 1 A0 5 1 2 3 4
Go here 2
Write failed 0
It does not go into "Go here 1", it means that no write command to the reader, do anyone know why?
That write command you are using seems to be wrong. You are using the COMPATIBILITY_WRITE command code (0xA0) but you pass the parameters of a WRITE command.
I suggest you stick to the WRITE command:
+-----------+------+------+---------------------+
| WRAPPING | CMD | ADDR | DATA (1 PAGE) |
+-----------+------+------+---------------------+
| 0x40 0x01 | 0xA2 | 0x05 | 0x01 0x02 0x03 0x04 |
+-----------+------+------+---------------------+
Or you could also use the COMPATIBILITY_WRITE command:
You start with sending the command and the address:
+-----------+------+------+
| WRAPPING | CMD | ADDR |
+-----------+------+------+
| 0x40 0x01 | 0xA0 | 0x05 |
+-----------+------+------+
You should then receive the ACK/NAK status from the tag.
Then you send the data in a second frame:
+-----------+---------------------+------------------------------------------------------------+
| WRAPPING | DATA (1 PAGE) | FILLER (3 EMPTY PAGES)
+-----------+---------------------+------------------------------------------------------------+
| 0x40 0x01 | 0x01 0x02 0x03 0x04 | 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+-----------+---------------------+------------------------------------------------------------+
Hopefully I've been struggling with this long enough to ask a question here...
I can't connect ATmega1280 with a cheaper version of JTAGICE mkII like this one. I'm trying to first set fuses for JTAG debugging. I've already done udev config as described here (and here).
EDIT: I'm able to connect my hardware on my computer via my JTAGICE in Windows using AVRStudio, so I'm already positive the wiring is ok.
All I'm getting is:
$ avrdude -P usb -c jtagmkii -p m1280 -U hfuse:w:0x1a:m
avrdude: jtagmkII_program_enable(): bad response to enter progmode command: RSP_ILLEGAL_JTAG_ID
avrdude: jtagmkII_program_enable(): bad response to enter progmode command: RSP_ILLEGAL_JTAG_ID
avrdude: JTAGEN fuse disabled?
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.
I've read this can help solving JTAGICE problems. Sadly, I don't understand how it could help, but maybe you do:
$ avarice --part atmega1280 --mkII --jtag usb --read-fuses --read-lockbits --debug
AVaRICE version 2.10, Feb 8 2010 07:22:18
Defaulting JTAG bitrate to 250 kHz.
Found JTAG ICE, serno: 070000004693
JTAG config starting.
Attempting synchronisation at bitrate 19200
command[0x01, 1]: 01
recv: 0x1b
recv: 0x00
recv: 0x00
recv: 0x1c
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 28 bytes
read: 86 01 ff 26 04 00 ff 26 04 01 07 00 00 00 46 93 4a 54 41 47 49 43 45 6d 6b 49 49 00
recv: 0xb9
recv: 0xfe
CRC OK
Got message seqno 0 (command_sequence == 0)
response: 86 01 FF 26 04 00 FF 26 04 01 07 00 00 00 46 93 4A 54 41 47 49 43 45 6D 6B 49 49 00
Found a device: JTAGICEmkII
Serial number: 07:00:00:00:46:93
JTAG ICE mkII sign-on message:
Communications protocol version: 1
M_MCU:
boot-loader FW version: 255
firmware version: 4.38
hardware version: 0
S_MCU:
boot-loader FW version: 255
firmware version: 4.38
hardware version: 1
command[0x02, 1]: 02 03 01
recv: 0x1b
recv: 0x01
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read: 80
recv: 0xcd
recv: 0x83
CRC OK
Got message seqno 1 (command_sequence == 1)
response: 80
command[0x0a, 1]: 0A 01
recv: 0x1b
recv: 0x02
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read: 80
recv: 0x1d
recv: 0x09
CRC OK
Got message seqno 2 (command_sequence == 2)
response: 80
Automatic device detection:
command[0x03, 1]: 03 0E
recv: 0x1b
recv: 0xff
recv: 0xff
recv: 0x06
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 6 bytes
read: e0 fe ff 00 00 00
recv: 0x82
recv: 0x16
CRC OK
Got message seqno 65535 (command_sequence == 3)
got asynchronous event: 0xe0
recv: 0x1b
recv: 0x03
recv: 0x00
recv: 0x05
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 5 bytes
read: 81 ff ff ff ff
recv: 0x24
recv: 0x19
CRC OK
Got message seqno 3 (command_sequence == 3)
response: 81 FF FF FF FF
JTAG id = 0xFFFFFFFF : Ver = 0xf : Device = 0xffff : Manuf = 0x7ff
Reported JTAG device ID: 0xFFFF
Looking for device: atmega1280
Configured for device ID: 0x9703 atmega1280 -- FORCED with atmega1280
command[0x0c, 1]: 0C FF FF FF FF FF 3D B9 F8 00 00 00 00 00 00 00 00 FF FF 1F E0 FF 1D A9 F8 00 00 00 00 00 00 00 00 73 FF 3F FF F7 3F F7 3F F7 3F 5F 3F 37 37 36 00 00 00 00 00 FF 0F 00 00 F7 3F 36 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 73 FF 3F F8 F7 3F F7 3F F7 3F 5F 2F 36 36 36 00 00 00 00 00 FF 0F 00 00 F7 3F 36 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 31 57 3B 00 01 08 00 FE 00 00 36 01 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3E 3D 00 02 00 00 00 00 00 01 00 00 02 00 00 00 3C 1F 00
recv: 0x1b
recv: 0x04
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read: 80
recv: 0xac
recv: 0x14
CRC OK
Got message seqno 4 (command_sequence == 4)
response: 80
JTAG config complete.
command[0x14, 1]: 14
recv: 0x1b
recv: 0x05
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read: a9
recv: 0xd0
recv: 0x29
CRC OK
Got message seqno 5 (command_sequence == 5)
response: A9
command[0x14, 2]: 14
recv: 0x1b
recv: 0x06
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read: a9
recv: 0x00
recv: 0xa3
CRC OK
Got message seqno 6 (command_sequence == 6)
response: A9
command[0x14, 3]: 14
recv: 0x1b
recv: 0x07
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read: a9
recv: 0xbf
recv: 0x22
CRC OK
Got message seqno 7 (command_sequence == 7)
response: A9
command[0x14, 4]: 14
recv: 0x1b
recv: 0x08
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read: a9
recv: 0x0d
recv: 0x93
CRC OK
Got message seqno 8 (command_sequence == 8)
response: A9
command[0x14, 5]: 14
recv: 0x1b
recv: 0x09
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read: a9
recv: 0xb2
recv: 0x12
CRC OK
Got message seqno 9 (command_sequence == 9)
response: A9
command[0x14, 6]: 14
recv: 0x1b
recv: 0x0a
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read: a9
recv: 0x62
recv: 0x98
CRC OK
Got message seqno 10 (command_sequence == 10)
response: A9
command[0x14, 7]: 14
recv: 0x1b
recv: 0x0b
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read: a9
recv: 0xdd
recv: 0x19
CRC OK
Got message seqno 11 (command_sequence == 11)
response: A9
command[0x14, 8]: 14
recv: 0x1b
recv: 0x0c
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read: a9
recv: 0xd3
recv: 0x85
CRC OK
Got message seqno 12 (command_sequence == 12)
response: A9
command[0x14, 9]: 14
recv: 0x1b
recv: 0x0d
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read: a9
recv: 0x6c
recv: 0x04
CRC OK
Got message seqno 13 (command_sequence == 13)
response: A9
command[0x14, 10]: 14
recv: 0x1b
recv: 0x0e
recv: 0x00
recv: 0x01
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 1 bytes
read: a9
recv: 0xbc
recv: 0x8e
CRC OK
Got message seqno 14 (command_sequence == 14)
response: A9
JTAG ICE: Cannot synchronise
The device is being recognized on my system
$ lsusb
Bus 002 Device 012: ID 03eb:2103 Atmel Corp. JTAG ICE mkII
It's also not behind any USB hub. I triple checked all connections. Any clues?
avrice is connecting to the unit fine, but the unit doesn't seem to be communicating with the target device. Are you sure it is connected and powered on?
This document may help you decipher what the jtag unit is responding.