I am fixing a bug in a parser for DWARF debug information (2nd DWARF version). In the process I made the following strange observation:
A bytestream was created by reading a dll file (created with ada files by GNAT). At the position of a "DW_TAG_structure_type" in debug_info inside this bytestream an additional byte with the value 1 has crept into the byte stream. Thereby all values in the FileInputStream are shifted by 1 byte.
This is how the original DIE in .debug_info looks like:
<1><3aa824>: Abbrev Number: 129 (DW_TAG_structure_type)
<3aa826> DW_AT_byte_size : 44
<3aa827> DW_AT_decl_file : 11
<3aa828> DW_AT_decl_line : 380
<3aa82a> DW_AT_artificial : 1
<3aa82b> DW_AT_sibling : <0x3aa888>
This is the corresponding scheme for the DIE in .debug_abbrev:
129 DW_TAG_structure_type [has children]
DW_AT_byte_size DW_FORM_data1
DW_AT_decl_file DW_FORM_data1
DW_AT_decl_line DW_FORM_data2
DW_AT_artificial DW_FORM_flag
DW_AT_sibling DW_FORM_ref4
DW_AT value: 0 DW_FORM value: 0
However, when I display the bytestream at this point, these values are shown:
Abbrev Number >>Strange Byte<< DW_AT_byte_size DW_AT_decl_file
81 01 2C 0B ...
(129) ?? (44) (11)
Does anyone know what this "Strange Byte" is all about?
Not really familiar with DWARF, but the DWARF 2.0 specification reads (section 7.5.3):
Following the tag encoding is a 1-byte value that determines whether a
debugging information entry using this abbreviation has child entries
or not. If the value is DW_CHILDREN_yes, the next physically
succeeding entry of any debugging information entry using this
abbreviation is the first child of the prior entry. If the 1-byte
value following the abbreviation’s tag encoding is DW_CHILDREN_no, the
next physically succeeding entry of any debugging information entry
using this abbreviation is a sibling of the prior entry. [...]
Finally, the child encoding is followed by a series of attribute
specifications. [...]
So, could this "strange byte" represent DW_CHILDREN_yes?
I'm also a little bit puzzled by the value 0x81 (129). The specification states that the tag encoding for DW_TAG_structure_type is 0x13 (which should fit in a byte), and the previous quote suggests that the tag encoding is followed by a byte that is not part of the tag encoding itself (if I understand correctly). So I would expect a stream of 0x13 0x01 (encoded tag + has child entries flag).
Related
I was modifying a piece of PC software I wrote to read multiple NDEF records from an NFC tag. However, one of the tags I have contains a record with what seems to be a mangled NDEF header. It's the last record of 6, the other 5 coming in as expected. I've listed it below. For simplicity, all values are listed in hexidecimal and the payload has been truncated.
Record #6
Header: 42
Type Length: 03
Random Bytes: 00 00 00
Payload Length: 2C (44)
Rec. Type: 6E 2F 70 (n/p)
Payload: **
As you can see, 3 random zero bytes are shoved between what should be the Type Length and Payload Length. I have double checked the Length Field in the TLV and found that it accounts for these 3 bytes. I'm not getting any data truncated off of the end of the TLV due to these added bytes.
I decided to do a sanity check with NXP's TagInfo app to make sure I wasn't just reading the data incorrectly. Checking the data dump from a full scan, I saw that the data does in fact match. I've listed the memory scan below. Only the relevant data points are listed and the payload is, again, truncated.
Memory Dump
addr data
...
[30] -- -- 42 03 |--B.|
[31] 00 00 00 2C |...,|
[32] 6E 2F 70 ** |n/p*|
[33] ** ** ** ** |****|
...
[3D] ** ** ** FE |***.|
...
We thought that maybe this was an issue with padding given that, in this case, the Terminator TLV appears at the end of page 0x3D. However, due to the nature of previous records, this is not always the case. Sometimes, the Terminator TLV shows up in the middle of a page.
However, the strange thing is that, in the same TagInfo app on the NDEF page, it reports the NDEF message as follows.
NDEF Message
...
[A8] 52 03 2C 6E 2F 70 ** ** |R.,n/p**|
[B0] ** ** ** ** ** ** ** ** |********|
...
[D8] ** ** |** |
...
Somehow, the software has not only removed the 3 extra bytes, but has correctly set the SR bit in the NDEF header. I have double checked this with another NFC app on Android and have confirmed that the other app is able to read the NDEF Message this way as well.
My question is, is there a reason or logic behind how the app is able to correct not only the the added bytes, but also the NDEF Header? I'm not sure if this is Android doing the correction or something else deeper in the NDEF message structure. Either way, I'm looking at the right way to make the correction while not effecting how I read the other 5 records held within this tag.
Those bytes are also part of the payload length
If the record does not have the SR (short record) bit set, then the payload length is 4 bytes long rather than one byte.
https://learn.adafruit.com/adafruit-pn532-rfid-nfc/ndef#payload-length-9-9
The first byte is 0x42, which in binary is 0100 0010. If we separate that out, we can see that the record has the ME (or 'Message End') bit set, as well as a TNF ('Type Name Format') of 0x02 - 'MIME Media Record'. The SR bit is bit 4, which is zero in this case.
That's also why they disappear in the version corrected by the TagInfo app - it has set the SR (which is why the header jumps to 0x52) and removed the unnecessary bytes.
This question already has answers here:
Reading correct data from NFC wrist band with NXP Mifare Ultralight in C
(1 answer)
Defining a NDEF Message
(2 answers)
Closed 5 years ago.
I'm trying to read NDEF records out of some NTAG213 & NTAG216 NFC tags, and I seem to be getting some extra bytes in the user memory i'm not expecting.
Based on the spec, the user memory should start from block 4, but when I read from the NTAG213 tags, i see 7 extra bytes before the NDEF record start, and 2 extra bytes for the NTAG216 tags.
Here's the example of the NTAG213 memory:
01| 04 ae f4 d6
02| 0a d7 49 80
03| 14 48 00 00
04| e1 10 6d 00
05| 03 db 91 01 <-- NDEF starts at 91?
06| 1a 54 02 65
07| 6e 43 4f 43
08| 4f 4e 55 54
09| 20 42 4f 44
10| 59 20 4d 49
11| ...
The NDEF record appears to start with the header byte (91) in block 05, rather than the start on block 04.
Does anyone know what the extra bytes are for, or how I can tell what the offset should be for reading back just the NDEF data?
The bytes look a bit like some of the "Memory content at delivery". But i'm not sure what the purpose is.
Storage of NDEF data on Type 2 Tags is defined by the NFC Forum Type 2 tag specification. This specification defines that the first four byte of the user memory (fourth page) describe the NDEF capabilities of the tag and that the following bytes contain a sequence of Type-Length-Value (TLV) constructs, one of those (T=3) is the NDEF Message TLV that contains the actual NDEF data. Other TLV's describe memory locations that contain tag specific data like lock bytes and must be skipped when reading or writing NDEF data.
Your example content is an NTAG216 (not NTAG213).
The content of the fourth page is a magic byte (0xE1) that indicates NDEF format, followed by the NDEF mapping version (0x10 => Version 1.0), followed by the raw tag capacity in multiples of 8 (0x6D * 8 == 872 byte user data), followed by the read/write permissions (0x00 => readable and writable w/o restrictions).
The fifth page starts with the NDEF TLV Type (0x03 => NDEF message), followed by the TLV Length (0xDB == 219 byte) which gives the TLV Value field size. The bytes following are the actual NDEF message data but be aware that for some tags this may not be contiguous memory (other TLVs may indicate memory bytes that must be skipped when reading or writing).
For all the bells and whistles you can study an ndef read and ndef write or obtain a copy of the Type 2 Tag specification from the NFC Forum specifications page.
I'm working on a Windows 2012 (NOT R2 and can't upgrade) AD environment. When I run the following piece of code from vbscript with an admin (not administrator) account, it runs perfectly. However when I run it with a normal user, I get a -2147463168 which seems to be a binding error.
On error Resume next
UsuariosLDAP = "LDAP://" & objSysInfo.UserNameSet
ObjUser = GetObject(UsuariosLDAP)
If err.number <> 0 then
strTipoError = "Error buscando objeto en LDAP " & CStr(Err.Number) & " Usuario:" & objSysInfo.UserName
shell.logevent 1, strTipoError
Wscript.Quit
end if
As it runs correctly with an admin account, I'll assume (looking for other options), that this is a permissions issue. The thing is that this a login script to be executed by all users, so I'm a bit leery of modifying permissions on all AD objects unless I really have to. The other thing is I've done something similar to this several times before (query a UserObject with a normal user) and it's always worked correctly. I'm not sure what has changed in 2012 to break this.
Thx a lot in advance
// MessageId: E_ADS_BAD_PATHNAME
//
// MessageText:
//
// An invalid directory pathname was passed
//
#define E_ADS_BAD_PATHNAME _HRESULT_TYPEDEF_(0x80005000L)
From ADSErr.h
Decoding Errors
-2147220978 style numbers are 32 bit signed integers, convert to hex with calculator.
Windows errors (smallish numbers) and COM HResults (typically, but with exceptions, start with an 8 as in 0x80040154) are defined in WinError.h, except 8007nnnn where you look up the Window error number that it contains.
As a general rule Windows errors are less than 65,535 (0xFFFF). Errors starting 0x80000001 are Component Object Model (COM) HResults. Errors starting 0xc0000001 are NTStatus results.
NTStatus errors (typically but not always start with an C as in 0xC0000022) are defined in NTStatus.h.
.h files are the best source because it includes the symbolic name of the error which can give clues such as the source of the error. FormatMessage doesn't give the symbolic name only the description.
You get these files by downloading the Platform SDK (it's gigabytes)
http://www.microsoft.com/en-us/download/details.aspx%3Fid%3D8279&sa=U&ei=w2IrULDDLsHFmAWbmIHoBg&ved=0CBwQFjAA&usg=AFQjCNHZn9-4f2NnuN9o3UWUsOF3wL7HBQ
If you just want the two files I have them on my skydrive so I can reference them anywhere I go.
https://skydrive.live.com/redir?resid=E2F0CE17A268A4FA!121
Note internet errors (12,000 - 12,999) are windows errors but are specified in wininet.h also available above.
There are errors defined in other .h files. But 99% are in the three above.
Structure of HResults and NTStatus Codes
The most significant bit in HResults, and the two most significant bits in NTStatus are set on error. Hence Hresults start 8 on error and NTStatus starts C on Error. The next 14 or 15 bits are reserved and some specify the facility - what area the error is in. This is the third and fourth number when reading hex. EG 0xnn07nnnn - An HResult facility code 7 is a normal Windows' error (returned from a COM program - hence it's returned as a HResult). Facility codes are defined in Winerror.h for HResults and NTStatus.h for NTStatus codes. They are different.
To Decode 0x8003nnnn Errors
HResults with facility code 3 means the HResult contains OLE Structured Storage errors (0x0 to 0xff). These are the same as Dos error codes. These don't seem to be in Windows' header files and the list of codes is at the end of this post.
To Decode 0x8004nnnn Errors
HResults with facility code 4 means the HResult contains OLE errors (0x0 to 0x1ff) while the rest of the range (0x200 onwards) is component specific errors so 20e from one component will have a different meaning to 20e from another component.
This is why the source of the error is extra important for errors above 0x80040200.
To Decode 0x8007nnnn Errors
HResults with facility code 7 means the HResult contains a Windows' error code. You have to look up the Windows' error code not the HResult.
To decode 0x80070002. The 0x means it's a hexadecimal number, the 8 means error, the first 7 means it a windows error, and the rest of the number, 2, is the actual Windows error.
To look up the error we need it in decimal format. Start Calculator (Start - All Programs - Accessories - Calculator) and choose View menu - Scientific, then View menu - Hex. Enter 2. Then View menu - Decimal. It will say 2.
Start a Command Prompt (Start - All Programs - Accessories - Command Prompt) and type
net helpmsg 2
and it will say
The system cannot find the file specified.
or look it up in winerror.h
//
// MessageId: ERROR_FILE_NOT_FOUND
//
// MessageText:
//
// The system cannot find the file specified.
//
#define ERROR_FILE_NOT_FOUND 2L
To Decode 0x8019nnnn Errors
HResults with facility 0x19 are HTTP errors. Codes under 16,384 (0x4000) are the same as HTTP errors, eg HTTP status 404: The requested URL does not exist on the server is 0x80190194 (0x194 = 404). Codes 16,384 and higher are BITS specific.
Dos Error Codes (for 0x8003nnnn errors)
Code Message
01 Invalid function number
02 File not found
03 Path not found
04 Too many open files (no handles left)
05 Access denied
06 Invalid handle
07 Memory control blocks destroyed
08 Insufficient memory
09 Invalid memory block address
0A Invalid environment
0B Invalid format
0C Invalid access mode (open mode is invalid)
0D Invalid data
0E Reserved
0F Invalid drive specified
10 Attempt to remove current directory
11 Not same device
12 No more files
13 Attempt to write on a write-protected diskette
14 Unknown unit
15 Drive not ready
16 Unknown command
17 CRC error
18 Bad request structure length
19 Seek error
1A Unknown media type
1B Sector not found
1C Printer out of paper
1D Write fault
1E Read fault
1F General failure
20 Sharing violation
21 Lock violation
22 Invalid disk change
23 FCB unavailable
24 Sharing buffer overflow
25 Reserved
26 Unable to complete file operation (DOS 4.x)
27-31 Reserved
32 Network request not supported
33 Remote computer not listening
34 Duplicate name on network
35 Network name not found
36 Network busy
37 Network device no longer exists
38 NetBIOS command limit exceeded
39 Network adapter error
3A Incorrect network response
3B Unexpected network error
3C Incompatible remote adapter
3D Print queue full
3E No space for print file
3F Print file deleted
40 Network name deleted
41 Access denied
42 Network device type incorrect
43 Network name not found
44 Network name limit exceeded
45 NetBIOS session limit exceeded
46 Temporarily paused
47 Network request not accepted
48 Print or disk redirection is paused
49-4F Reserved
50 File already exists
51 Reserved
52 Cannot make directory entry
53 Fail on INT 24
54 Too many redirections
55 Duplicate redirection
56 Invalid password
57 Invalid parameter
58 Network device fault
59 Function not supported by network (DOS 4.x)
5A Required system component not installed (DOS 4.x)
Facility Codes
NTStatus Facilities HResults Facilities
Common status values 0x0 Null 0x0
Debugger 0x1 Rpc 0x1
Rpc_runtime 0x2 Dispatch 0x2
Rpc_stubs 0x3 Storage 0x3
Io_error_code 0x4 Itf 0x4
Various drivers 0x5-0xf Win32 0x7
Ntwin32 0x7 Windows 0x8
Ntsspi 0x9 Sspi 0x9
Terminal_server 0xa Security 0x9
Faciltiy_mui_error_code 0xb Control 0xa
Usb_error_code 0x10 Cert 0xb
Hid_error_code 0x11 Internet 0xc
Firewire_error_code 0x12 Mediaserver 0xd
Cluster_error_code 0x13 Msmq 0xe
Acpi_error_code 0x14 Setupapi 0xf
Sxs_error_code 0x15 Scard 0x10
Transaction 0x19 Complus 0x11
Commonlog 0x1a Aaf 0x12
Video 0x1b Urt 0x13
Filter_manager 0x1c Acs 0x14
Monitor 0x1d Dplay 0x15
Graphics_kernel 0x1e Umi 0x16
Driver_framework 0x20 Sxs 0x17
Fve_error_code 0x21 Windows_ce 0x18
Fwp_error_code 0x22 Http 0x19
Ndis_error_code 0x23 Usermode_commonlog 0x1a
Hypervisor 0x35 Usermode_filter_manager 0x1f
Ipsec 0x36 Backgroundcopy 0x20
Maximum_value 0x37 Configuration 0x21
State_management 0x22
Metadirectory 0x23
Windowsupdate 0x24
Directoryservice 0x25
Graphics 0x26
Shell 0x27
Tpm_services 0x28
Tpm_software 0x29
Pla 0x30
Fve 0x31
Fwp 0x32
Winrm 0x33
Ndis 0x34
Usermode_hypervisor 0x35
Cmi 0x36
Windows_defender 0x50
after looking into the code it seems that the error handling was hiding the real error that had to do with parsing the memberof attribute. Once I modified the error handling I detected the original error and corrected it.
Thx to all for your help
Cheers
If you look under the section "802.15.4 Frame Format" on this page you will see it defines
Preamble Sequence : 4 octets
Start Frame Delimiter (SFD) : 1 octet
In the AT86RF233's data sheet on pg. 76 Section 8.1.1.1 in the SFD is predefined to be
0xA7
But the preamble does not have a predefined value, so what should I define it to be? I don't see any indication in the data sheet explaining this further.
From the AT86RF233 data sheet (p.76):
8.1.1 PHY Protocol Data Unit (PPDU)
8.1.1.1 Synchronization Header (SHR)
The SHR consists of a four-octet preamble field (all zero), followed by a single byte
start-of-frame delimiter (SFD) which has the predefined value 0xA7. During transmission, the SHR is automatically generated by the Atmel AT86RF233, thus the Frame Buffer shall contain PHR and PSDU only, see Section 6.3.2. […]
So, to me it looks like the preamble is made of 32 consecutive Zero-Bits. However, I am curious why you need to "define" the preamble, as it is automatically generated by the hardware and cannot be modified by configuration.
I want to be able to find out where the code appearing at the entry point comes from by looking at the PE header.
For example, this piece of code is the starting code of my program(401000h)
00401000 >/$ 58 POP EAX ; kernel32.76E93677
00401001 |. 2D 77360100 SUB EAX,13677
00401006 |. BB 4A184000 MOV EBX,<JMP.&kernel32.VirtualProtect>
I want to know where this code comes from. How can I find it without manually scanning my file? (to complete the example, here's an hexdump from the same file, the code now resides at 200h)
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
00000200 58 2D 77 36 01 00 BB 4A 18 40 00
How can I get from my virtual entry point (401000h) to the raw entry point (200h)?
I tried solving it myself of course. But I'm missing something. At first I thought:
.text[ Entrypoint (1000h) - VirtualOffset (1000d) ] = raw entrypoint
since the file alignment = 200, and the raw entry point was at the very start of my .text section, I thought I could use this for all the executables.
Solved, I made stupid mistakes when calculating the raw entry point
.text[ Entry point - Virtual offset ] + File Alignment = Raw entry point (relative to .text section)
To locate the offset in the file by yourself you need to have a look at the _IMAGE_NT_HEADERS structure. From this you can get the IMAGE_OPTIONAL_HEADER where
the member you are interested in ImageBase is. You can change its value with EditBin /REBASE so there is little need to roll your own tool.
For reference how you can determine the entry point via dumpbin.
You can use
dumpbin /headers
dumpbin /headers \Windows\bfsvc
Dump of file \Windows\bfsvc.exe
PE signature found
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
14C machine (x86)
4 number of sections
4A5BBFB3 time date stamp Tue Jul 14 01:13:55 2009
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
102 characteristics
Executable
32 bit word machine
OPTIONAL HEADER VALUES
10B magic # (PE32)
9.00 linker version
DE00 size of code
2000 size of initialized data
0 size of uninitialized data
4149 entry point (01004149)
1000 base of code
F000 base of data
1000000 image base (01000000 to 01011FFF)
1000 section alignment
200 file alignment
For the entry point the image base value is relevant. But this is only true for images that are not ASLR enabled. For them a random base address (1 of 128 different ones) is choosen.
The flag that indicates if an image is ASLR enabled is the value 0x40 which is set in DLL characteristics.
8140 DLL characteristics
For svchost.exe for example it is set for older programs it is generally 0.
Yours,
Alois Kraus
Have a look at this thread including an answer with a detailed explanation: Calculating the file offset of a entry point in a PE file
AddressOfRawEntryPoint (in EXE file) = AddressOfEntryPoint + .text[PointerToRawData] - .text[VirtualAddress]