I have samsung disk after a while the device is found on /dev/sdb but not the partitions. The smartools is not able to make a test of the unit and the dmesg traces show the follow information about is not able to access sector 0. For me the problem is clear the disk is broken in some hardware part and the PCB board is not able to communicate with the disk. I would like have some other point of view about the problem, keeping in mind is a hardware problem.
[11087.417346] sd 4:0:0:0: [sdb] tag#0 uas_zap_pending 0 uas-tag 1 inflight: CMD
[11087.417354] sd 4:0:0:0: [sdb] tag#0 CDB: Read(16) 88 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00
[11087.417422] sd 4:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[11087.417426] sd 4:0:0:0: [sdb] tag#0 CDB: Read(16) 88 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00
[11087.417429] print_req_error: I/O error, dev sdb, sector 0
[11087.417439] Buffer I/O error on dev sdb, logical block 0, async page read
[11087.417518] ldm_validate_partition_table(): Disk read failed.
[11087.417569] Dev sdb: unable to read RDB block 0
[11087.417647] sdb: unable to read partition table
[11087.737073] sd 4:0:0:0: [sdb] Read Capacity(16) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[11087.737078] sd 4:0:0:0: [sdb] Sense not available.
[11087.977053] sd 4:0:0:0: [sdb] Read Capacity(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[11087.977057] sd 4:0:0:0: [sdb] Sense not available.
[11088.073054] sd 4:0:0:0: [sdb] 0 512-byte logical blocks: (0 B/0 B)
[11088.073057] sd 4:0:0:0: [sdb] 4096-byte physical blocks
[11088.285077] sd 4:0:0:0: [sdb] Attached SCSI disk
[12440.024126] usb 2-3: new high-speed USB device number 20 using xhci_hcd
[12440.217672] usb 2-3: New USB device found, idVendor=04e8, idProduct=61b6
[12440.217678] usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[12440.217680] usb 2-3: Product: Samsung M3 Portable
[12440.217683] usb 2-3: Manufacturer: Samsung M3 Portable
[12440.217685] usb 2-3: SerialNumber: BFB47DFB1D000023
[12440.219046] scsi host4: uas
[12440.230061] scsi 4:0:0:0: Direct-Access Samsung M3 Portable 1306 PQ: 0 ANSI: 6
[12440.230907] sd 4:0:0:0: Attached scsi generic sg2 type 0
[12452.230564] sd 4:0:0:0: [sdb] Spinning up disk...
[12455.236046] .
[12462.276102] .
[12468.900015] .
[12475.940060] .
[12482.980062] .
[12490.019988] .
[12492.293889] not responding...
[12492.294535] sd 4:0:0:0: [sdb] 281474976710656 512-byte logical blocks: (144 PB/128 PiB)
[12492.294537] sd 4:0:0:0: [sdb] 4096-byte physical blocks
[12492.294687] sd 4:0:0:0: [sdb] Write Protect is off
[12492.294688] sd 4:0:0:0: [sdb] Mode Sense: 53 00 00 08
[12492.295029] sd 4:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[12492.295257] sd 4:0:0:0: [sdb] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
[12492.295684] sd 4:0:0:0: [sdb] Unit Not Ready
[12492.295687] sd 4:0:0:0: [sdb] Sense Key : Hardware Error [current]
[12492.295689] sd 4:0:0:0: [sdb] Add. Sense: Internal target failure
Do you have some idea what is going on? Can I recover the disk?
Related
I have an NXP NTAG216 and I want to know the storage size of the tag. From the specification I read that the size of the data area is in Block 3 Byte 2 which is 7F in my case which is 127 in decimal and times 8 Bytes it is 1016 Bytes. From the NXP website It states that the tag only has 924 Bytes NXP NTAG 213/215/216.
[0] 04 : 91 : 52 : 4F
[1] 9A : 9A : 40 : 80
[2] C0 : 48 : 00 : 00
[3] E1 : 10 : 7F : 00
Similar with a NXP NTAG215 which has 3E in decimal 62 times 8 Bytes is 496 Bytes where the website says 540 Bytes.
[0] 04 : 34 : DB : 63
[1] 6A : 83 : 5C : 81
[2] 34 : 48 : 00 : 00
[3] E1 : 10 : 3E : 00
Can someone explain to me how this number is calculated?
If you read the datasheet for cards https://www.nxp.com/docs/en/data-sheet/NTAG213_215_216.pdf
It says
NTAG216 EEPROM:
924 bytes, organized in 231 pages of 4 byte per page.
26 bytes reserved for manufacturer and configuration data
37 bits used for the read-only locking mechanism
4 bytes available as capability container
888 bytes user programmable read/write memory
From the spec for Type 2 cards http://apps4android.org/nfc-specifications/NFCForum-TS-Type-2-Tag_1.1.pdf
The Capability Container Byte 2 indicates the memory size of the data area of the Type 2 Tag Platform. The value of byte 2 multiplied by 8 is equal to the data area size measured in bytes
Note your question said multiply by 8Bits (1 Byte) which is wrong, I'm sure this was just a typo and you meant 8Bytes
So some of the headline 924 bytes is actually reserved for other uses and would never be included in the size listed in the Capability Container that leave 888 bytes to use of user usable memory.
The datasheet says the value in the should be 6Dh which is 109 * 8 = 872 bytes.
And all my NTAG216 have a value of 6Dh
I'm not sure why this value Capability Container value is less than the actual usable memory size, it might because the wording of the spec is unclear but it might be "usable data area" of a NDEF message and might not include the mandatory headers (TLV, etc) that make up a valid NDEF message and Records.
So the the NTAG215 example value of 3Eh is exactly as the datasheets says it should be and smaller than the total memory size as outlined above because some memory pages are reserved for non NDEF data, etc.
The next question is why is your NTAG216 example not have the correct value of 6Dh
The spec for Type 2 cards and the datasheet the NTAG21x cards says:-
The Capability Container CC (page 3) is programmed during the IC production according to the NFC Forum Type 2 Tag specification (see Ref. 2). These bytes may be bit-wise modified by a WRITE or COMPATIBILITY_WRITE command. The parameter bytes of the WRITE command and the current contents of the CC bytes are bit-wise OR’ed. The result is the new CC byte contents. This process is irreversible and once a bit is set to logic 1, it cannot be changed back to logic 0.
The 4 bytes of the Capability Container have to be writeable because you can only write in blocks of 4 bytes and Byte 3 of the Capability Container indicates the read and write access capability of the data area and CC area of the Type 2 Tag Platform and therefore can be legitimately changed to make the card read only.
So it is possible that a bad write to the Capability Container has increased the value of the Byte 2 (size value) to an invalid value on this particular card.
The other possibility is that there are a lot of Fake NTAG21x cards around, may be this is a fake card with actually more memory than a genuine NXP card.
Either use the Originality signature method outlined in the datasheet to verify it is genuine or the Taginfo smartphone App from NXP will also verify it is genuine.
Assume a simple hello world in C, compiled using gcc -c to an object file and disassembled using objdump will looks like this:
_main:
0: 55 pushq %rbp
1: 48 89 e5 movq %rsp, %rbp
4: c7 45 fc 00 00 00 00 movl $0, -4(%rbp)
b: c7 45 f8 05 00 00 00 movl $5, -8(%rbp)
12: 8b 05 00 00 00 00 movl (%rip), %eax
As you can see the memory addresses are 0, 1, 4, .. and so on. They are not actual addresses.
Linking the object file and disassembling it looks like this:
_main:
100000f90: 55 pushq %rbp
100000f91: 48 89 e5 movq %rsp, %rbp
100000f94: c7 45 fc 00 00 00 00 movl $0, -4(%rbp)
100000f9b: c7 45 f8 05 00 00 00 movl $5, -8(%rbp)
100000fa2: 8b 05 58 00 00 00 movl 88(%rip), %eax
My question is, is 100000f90 an actual address of a byte of virtual memory or is it an offset?
How can the linker give an actual address prior to execution? What if that memory address isn't available when executing? What if I execute it on another machine with much less memory (maybe paging kicks in here).
Is't it the job of the loader to assign actual addresses?
Is the linker generating actual addresses for he final executable file?
(The following answers assume that the linker is not creating a position-independent executable.)
My question is, is 100000f90 an actual address of a byte of virtual memory or is it an offset?
It's the actual virtual address. Strictly speaking, it is the offset from the base of the code segment, but since modern operating systems always set the base of the code segment to 0, it is effectively the actual virtual address.
How can the linker give an actual address prior to execution? What if that memory address isn't available when executing? What if I execute it on another machine with much less memory (maybe paging kicks in here).
Each process gets its own separate virtual address space. Because it is virtual memory, the amount of physical memory in the machine doesn't matter. Paging is the process by which virtual addresses get mapped to physical address.
Isn't it the job of the loader to assign actual addresses?
Yes, when creating a process, the operating system loader allocates physical page frames for the process and maps the pages into the process's virtual address space. But the virtual addresses are those assigned by the linker.
Does a linker generate absolute virtual addresses when linking
It depends upon the linker setting and the input source. For general programming, linkers usually strive to create position independent code.
My question is, is 100000f90 an actual address of a byte of virtual memory or is it an offset?
It is most likely an offset.
How can the linker give an actual address prior to execution?
Think about the loader for an operating system. It expects things to be in specific address locations. Any decent linker will allow the programmer to specify absolute addresses some way.
What if that memory address isn't available when executing? What if I execute it on another machine with much less memory (maybe paging kicks in here).
That's the problem with position-dependent code.
Is't it the job of the loader to assign actual addresses?
The job of the loader is to follow the instructions given to it in the executable file. In creating the executable, the linker can specify addresses or defer to the loader in some cases.
I have a Felica card. The first question is what actually is this card? Is it a Smart Card or it is a simple memory card? Is it a kind of Java Card and can I load .cap files inside or it has its proprietary fixed contents and I can't load any applet? Is it GlobalPlatform standard complaint?
I read here that:
Sony’s proprietary FeliCa is a smartcard technology that is similar to
ISO/IEC
14443. FeliCa has a file system similar to that defined in ISO/IEC 7816-4. The file system and commands for access to the file system are
standardized in JIS X 6319-4 [28]. In addition, the FeliCa system has
proprietary cryptography and security features.
After that I tried to send some APDU commands to it. The first step was do some configuration changes with the reader. Because my reader is configured to read ISO14443 Type A and Type B cards and not Felica cards.
As both Felica and ISO/IEC 14443 cards use 13.56 MHz frequency for the carrier, I think the difference between these types is in the Protocol layer only. Am I right? If so, what is the name of Felica cards transmission protocol? (For ISO/IEC 14443 cards, we have T=1 and T=CL protocols).
After configuring the reader, I tried to send commands to card:
Connect successful.
Send: 00 A4 04 00 00
Recv: 6A 81
Time used: 31.000 ms
Send: 00 C0 00 00 00
Recv: 6A 81
Time used: 28.000 ms
Send: 00 CA 00 00 00
Recv: 6A 81
Time used: 35.000 ms
As you see above, I receive 0x6A81 status words only.
I also searched a lot of ACS Reader Datasheets, Some NXP Application notes and for sure JIS X 6319-4 standard for a list of commands for this type of cards. But I found nothing applicable.
So, the questions are:
What actually is Felica? (Smart? Memory?)
What is the difference between Felica cards and ISO/IEC14443 cards? Is it related to NFC?
How to communicate with this card and transfer data?
Update:
My card'S ATR is : 3b 8f 80 01 80 4f 0c a0 00 00 03 06 11 00 3b 00 00 00 00 42
What actually is Felica? (Smart? Memory?)
It's more like a memory card than a smart card with regards to functionality. Reading data in blocks is typical for a memory card and the card has very limited functionality besides basic authentication based on symmetric cryptography.
You could argue that it is a smart card in the sense that the implementation seems to carry a multi-purpose CPU (see Annex B).
It seems however impossible to change the behavior of the smart card the same way you'd do e.g. in a Global Platform Java Card. So I'd classify it as a memory card with a proprietary protocol.
What is the difference between Felica cards and ISO/IEC14443 cards? Is it related to NFC?
It uses a proprietary communication protocol which includes both the data -link layer (which you are asking about here) and the command/response layer.
How to communicate with this card and transfer data?
The fact that you are sending APDU's instead of FeliCa's proprietary command / response pairs indicate that you are using a translation layer. This translation layer is likely to be in the reader / reader driver. The API of this translation layer is likely to be specified in the PCSC 2.01 specifications (section 3.2.2.1 Storage Card Functionality Support, using CLA byte 0xFF).
You probably need the reader's user manual as well, if just to figure out in which location to store the required keys.
When I disassembly a binary (compiled with g++) with objdump, I often see "random" bytes at the end of the contained functions, such as:
4005a5: 66 66 2e 0f 1f 84 00 data32 nopw %cs:0x0(%rax,%rax,1)
4005ac: 00 00 00 00
What are those bytes? Why the compiler put them there?
EDIT:
apparently those bytes represent a long NOP instruction put there by the compiler to keep functions 16-byte aligned. The weird thing is that the only function which is not 16-byte aligned is the main function. Are there any reasons?
I am trying to learn more about how to read process memory. So I opened the "entire memory" of the Firefox process in WinHex and saw the following hex values starting at offset 10000.
00 00 00 00 00 00 00 00 EC 6B 3F 80 0C 6D 00 01 EE FF EE FF 01 00 00 00
My question is
Is it possible for a human to interpret this without further knowledge? Are these pointers or values? Is there anything, which is common for different programs created with different compilers with regards to the process memory apart from things like endianness? Why does it start with lots of zeroes, isn't that a very odd way to start using space?
Obviously, you can't do anything "without further knowledge". But we already know a whole lot from the fact that it's Windows. For starters, we know that the executable gets its own view of memory, and in that virtual view the executable is loaded at its preferred starting address (as stated in the PE header of the EXE).
The start at 0x00010000 is a compatibility thing with MS-DOS (yes, that 16 bit OS) - the first 64KB are reserved and are never valid addresses. The pages up to 0x00400000 (4MB) are reserved for the OS, and in general differ between OS versions.
A common data structure in that range is the Process Environment Block. With the WinDBG tool, and the Microsoft Symbol Server, you can figure whether the Process Envirionment Block is indeed located at offset 0x10000, and what its contents mean.