I want to read around 336 bytes of data from NVRAM using Read Memory By Address UDS service. The command I am giving is "23 22 1C 22 01 50", where
0x23 - UDS command for Read Memory By Address
0x22 - Address and Length Format Identifier (Memory
address parameter - 2 and Memory size parameter 2)
0x1C 0x22 - Memory Address in 2 bytes
0x01 0x50 - Data length to read in 2 bytes (length is 336 bytes)
When I submit the command, I am getting "0x13 Incorrect Message Length or Invalid Format Error".
Can someone help me fixing this problem.
Thanks in advance.
Reference: https://piembsystech.com/uds-protocol/
What NRC 0x13 means
According to ISO 14229-1:2020:
This means:
SID 0x23 is supported by the server otherwise you would receive NRC 0x11 serviceNotSupported
Your request has inproper format (it is either too long or too short), in other cases you would receive other NRC (e.g. 0x31 requestOutOfRange). I suspect that address value is not 2 bytes long. It might be 4 bytes long (it depends on the memory type and size), but it is just a guess.
How to send the request properly
Well we do not know what is the exact format that the server accepts (it depends on memory of the server), but the ISO 14229-1:2020 define SID 0x23 request format as below:
I would try following request:
0x22 0x44 0x00 0x00 0x1C 0x22 0x00 0x00 0x01 0x50
where:
0x00 0x00 0x1C 0x22 - 4-byte memoryAddress
0x00 0x00 0x01 0x50 - memorySize (it is also 4 byte to make sure that addressAndLengthFormatIdentifier is properly interpreted by the server)
Other options
Server might have defect(s) (especially if you succesfully read memory using 2-byte-long address) and incorrectly display NRC 0x13 or have only support for certain value of addressAndLenghtFormatIdentifier. It is hard to judge with 100% certainty though. You would have provide at least one request with positive response.
Please do so in the comment and I am going to guide you through the problem.
Related
I am reading from COM port (communicating with RS-232).
I noticed a strange behavior when Win32 was reading 0x00 characters. I confirmed it by sending all possible combinations (from 0x00 to 0xF):
0x00 is read as 0x20.
Since my code can read all other Hex data, it is not a code issue right?
ANSWER TO MY QUESTION:
I forgot I replaced the input 0 character with the space character:
else if(buf[i] == 0)
{
//usually this happens in the beggining of a line.
buf[i] = ' ';//null
}
because usually every line I was reading was starting with 0.
So I removed the above code in my main and it fixed
I am having trouble reading and writing to different NFC tags with OMNIKEY 5426G2.
I can read and write the first 16 pages (4 bytes each) but the moment I send a command to read the 17th page - I get an error 0x6A 0x82 which means that address does not exist.
For example sending 0xFF 0xB0 0x00 0x06 0x04 gets me the 4 bytes on the 6th page
But when I do 0xFF 0xB0 0x00 0x10 0x04 - I get 0x6A 0x82 in return saying that this address does not exist.
All the tags that I use have this problem - different NTAG's, Mifare Ultralight C tags but ICODE SLIX tags are fine.
P.S. The same PC/SC commands work perfectly fine with ACR1252 reader so this is something related to OMNIKEY reader. Maybe some extra commands are missing.
P.P.S. Strange thing is that I can read/write all the bytes and pages by using a demo version of this library https://smartcard-api.com/buy-smart-card-api-library-license/
And since they are also using PC/SC commands - it clearly says that I am missing something.
Please help me understand what is going on. Thanks!
I'm trying to switch a Mifare Plus card into SL1 mode using an Omnikey 5421, however using the "Generic card command" interface as instructed by the documentation does not seem to work (card does not return any kind of output except 0x9000 which seems to be only an ACK that the command was sent succesfully - there should be additionaly bytes in the response before 0x90 0x00 which come from the chip itself).
The sequence is sent using SCardTransmit:
0xFF 0xA0 0x00 0x07 0x03 0x01 0x00 0x01 - enter generic session - returns 0x9000
... additional commands using documentation:
0xFF 0xA0 0x00 0x05 6+n 01 00 F3 00 00 64 + Mifare+ command 00 - returns 0x9000 whatever the command, even if invalid Mifare+ commands
0xFF 0xA0 0x00 0x07 0x03 0x01 0x00 0x02 - exit generic session - returns 0x9000 still
The only commands that seem to work are enter and exit, any other command that I send in between does not seem to have any effect, including RATS, Writeperso or Commitperso. When I add the 00 Le byte at the end the return code is 0x6400 instead of 0x9000, even though the docs say that Le byte should be appended when issuing Mifare+ commands.
All other operations work ok once the cards is personalized in SL1 mode (read, write, authenticate). I can already switch the card to SL1 mode using android NFC, so it does not seem to be a problem with the algorithm or the card.
I've tried to use command from the PC/SC part 3 documentation, but the return code is "not supported", so it seems that only this mechanism of transparent channel is available to issue 14443A commands.
In SL0 and SL3, You may directly call the Plus command via Generic Card Command.
"generic session" should be for SL1 to accept Plus command(as by default it goes to mifare classic mode)
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
What is the MozWebSocket firefox binary message client -> server packet structure?
Sending ArrayBuffer (0x01 0x00 0x01). Really sent 0x88 0x82 0xE7 0xEB 0x20 0x30 0xE4 0x03. First 2 bytes doesnt change on different sessions (id size?).
Here is for example chrome binary message packet structure -
0x82 - id
0xYY 1bit - is masked? 7bit - data length
0xZZ oxZZ oxZZ oxZZ - 4 byte mask
data (masked)
Note: Firefox currently only supports sending strings.
Seems like there is no way to send binary data using firefox?
Only Chrome currently supports sending binary object types. Firefox does not yet support sending binary types. However, Mozilla is working on the issue so there should be support in a Firefox release soon.
I believe the packet structure is identical to Chrome's (or any other browser's). Looking at the data framing section of the latest spec suggests that this is a connection close message:
0x88: The leading 8 shows that this is the final fragment of the message. The trailing 8 is the opcode for a connection close frame.
0x82: The msb shows that the message contains a mask. The remaining 7 bits give the length of data sent - 2 bytes in this case.
0xE7 0xEB 0x20 0x30: The mask used to decode the message.
0xE4 0x03: The message sent - (0xE4^0xE7) (0x03 ^ 0xEB) [ == 0xE7 0x0C I think]
Assuming you aren't closing the connection client side, you could check whether your version of Firefox supports sending binary messages.