I have this command as reference:
XX 2C 03 XX
When I send the command: "00 2C 03 01 00" I'm getting error 6d00 (Instruction code not supported or invalid)
Important: I am in a test environment, I am studying the APDU commands.
After testing questions I sent the command to verify the PIN containing an invalid PIN 3 times in a row.
Original PIN: 1574
P1 = 0x15
P2 = 0x15
Commands:
>> 0x00,0x20,0x00,0x80,0x08,0x24,p1,p2,0xFF,0xFF,0xFF,0xFF,0xFF
<< 63c2
>> 0x00,0x20,0x00,0x80,0x08,0x24,p1,p2,0xFF,0xFF,0xFF,0xFF,0xFF
<< 63c1
>> 0x00,0x20,0x00,0x80,0x08,0x24,p1,p2,0xFF,0xFF,0xFF,0xFF,0xFF
<< 63c0
After that, I run the command again:
>> 0x00,0x20,0x00,0x80,0x08,0x24,p1,p2,0xFF,0xFF,0xFF,0xFF,0xFF
<< 6983
I want to reset the counter (Reset Retry Counter), so that I can verify the PIN again, for this purpose I am executing the following command:
>> 00 2C 03 00
<< 6d00
Why am I getting this error: "6d00"?
I was forgetting the PUK code, problem solved!
The correct is:
CL ='00' -
INS='2C' - RESET RETRY COUNTER
P1 = either
'00' - Data contains PUK and new PIN
'01' - Data contains PUK only
P2 ='01' - Key Reference of the PIN (as <01>)
Data = either
PUK | NewPIN, if P1='00'
PUK , if P1='01'
Related
I have an archive encoded with gzip 1.5. I'm unable to decode it using the C zlib library. zlib inflate() return EC -3 stream.msg = "unknown compression method".
$ gzip --list --verbose vmlinux.z
method crc date time compressed uncompressed ratio uncompressed_name
defla 12169518 Apr 29 13:00 4261643 9199404 53.7% vmlinux
The first 32 bytes of the file are:
00000000 1f 8b 08 08 29 f4 8a 60 00 03 76 6d 6c 69 6e 75 |....)..`..vmlinu|
00000010 78 00 ec 9a 7f 54 1c 55 96 c7 6f 75 37 d0 fc 70 |x....T.U..ou7..p|
I see the first 18 bytes are the RFC-1952 gzip header.
After the NULL, I expect the next byte to be RFC-1951 deflate or RFC-1950 zlib (I'm not sure which)
So, I pass zlib inflate() a z_stream:next_in pointing to to the byte #0x12.
If this were deflate encoded, then I would expect the next byte #0x12 to be 0aabbbbb (BFINAL=0 and BTYPE=some compression)
If this were zlib encoded, I would expect the next byte #0x12 to take the form 0aaa1000 bbbccccc
Instead, I see #0x12 EC = 1110 1100 Which fits neither of those.
For my code, I took the uncompress() code and modified it slightly with allocators appropriate to my environment and several different experiments with the window bits (including 15+16, -MAX_WBITS, and MAX_WBITS).
int ZEXPORT unzip (dest, destLen, source, sourceLen)
Bytef *dest;
uLongf *destLen;
const Bytef *source;
uLong sourceLen;
{
z_stream stream;
int err;
stream.next_in = (Bytef*)source;
stream.avail_in = (uInt)sourceLen;
/* Check for source > 64K on 16-bit machine: */
if ((uLong)stream.avail_in != sourceLen) return Z_BUF_ERROR;
stream.next_out = dest;
stream.avail_out = (uInt)*destLen;
if ((uLong)stream.avail_out != *destLen) return Z_BUF_ERROR;
stream.zalloc = (alloc_func)my_alloc;
stream.zfree = (free_func)my_free;
/*err = inflateInit(&stream);*/
err = inflateInit2(&stream, 15 + 16);
if (err != Z_OK) return err;
err = inflate(&stream, Z_FINISH);
if (err != Z_STREAM_END) {
inflateEnd(&stream);
return err == Z_OK ? Z_BUF_ERROR : err;
}
*destLen = stream.total_out;
err = inflateEnd(&stream);
return err;
}
How can I correct my decoding of this file?
That should work fine, assuming that my_alloc and my_free do what they need to do. You should verify that you are actually giving unzip() the data that you think you are giving it. The data you give it needs to start with the 1f 8b.
(Side comment: "unzip" is a lousy name for the function. It does not unzip, since zip is an entirely different format than either gzip or zlib. "gunzip" or "ungzip" would be appropriate.)
You are manually reading the bits in the deflate stream in the wrong order. The least significant bits are first. The low three bits of ec are 100, indicating a non-last dynamic block. 0 for non-last, then 10 for dynamic.
You can use infgen to disassemble a deflate stream. Its output for the 14 bytes provided is this initial portion of a dynamic block:
dynamic
count 286 27 16
code 0 5
code 2 7
code 3 7
code 4 5
code 5 5
code 6 4
code 7 4
code 8 2
code 9 3
code 10 2
code 11 4
code 12 4
code 16 7
code 17 7
lens 4 6 7 7 7 8 8 8 7 8
repeat 3
lens 10
Is there a way to read a z/OS JCL input stream more than once? (one that comes from a //SYSIN DD *). I know I could cache the stream the first time I read it, and then read from the cached data, but I'm not interested in that solution.
Note: the language is Assembler
Depends on the language. This answer provides an example in HLASM and a reference to the 'C' Language reference at the end.
For Assembler you'll need to REWIND when you CLOSE the DCB. See the label at FINISH to see how this is done.
There may be other ways but this worked for me on z/OS 2.4
PRINT NOGEN
* ------------------------------------------------------------------- *
* *
* SYSIN2 *
* *
* #author Hogstrom *
* *
* Test to see if one can re-read SYSIN more than one time. *
* *
* ------------------------------------------------------------------- *
R0 EQU 0
R1 EQU 1
R2 EQU 2
R3 EQU 3 * Number of times to loop
R4 EQU 4
R5 EQU 5
R6 EQU 6
R7 EQU 7
R8 EQU 8
R9 EQU 9
R10 EQU 10
R11 EQU 11
R12 EQU 12 * Base Register
R13 EQU 13
R14 EQU 14
R15 EQU 15
*
SYSIN2 CSECT
STM R14,R12,12(R13)
LR R12,R15
USING SYSIN2,12
*
ST R13,SaveArea+4
LA R0,SaveArea
ST R0,8(R13)
LA R13,SaveArea
*
OPEN (SYSIN,(INPUT))
OPEN (SYSOUT,(OUTPUT))
LA R3,3 Number of times to read SYSIN
*
GETAGAIN DS 0H
GET SYSIN,INREC Read the next rec
PUT SYSOUT,INREC Write that bad boy out
B GETAGAIN
FINISH DS 0H Invoked at End of Data of SYSIN
CLOSE (SYSIN,REWIND) Close SYSIN and rewind
OPEN (SYSIN,(INPUT)) Open it up again
BCT R3,GETAGAIN Repeat the madness
*
CLOSE SYSIN
CLOSE SYSOUT
*
L R13,SaveArea+4
LM R14,R12,12(R13)
XR R15,R15
BR R14
*
SYSIN DCB DSORG=PS,MACRF=(GM),DDNAME=SYSIN,EODAD=FINISH, *
RECFM=FB,LRECL=80,BLKSIZE=0
SYSOUT DCB DSORG=PS,MACRF=(PM),DDNAME=SYSOUT, *
RECFM=FBA,LRECL=133,BLKSIZE=0
*
INREC DC CL132' '
SaveArea DS 18F
LTORG
END
Assemble the above and execute this JCL
//SYSIN2 JOB (CCCCCCCC),'HOGSTROM',
// MSGLEVEL=(1,1),
// MSGCLASS=O,
// CLASS=A,
// NOTIFY=&SYSUID
//*
//STEP1 EXEC PGM=SYSIN2
//STEPLIB DD DSN=USER1.TEST.LOADLIB,DISP=SHR
//*
//SYSIN DD *
REC 1 OF 3
REC 2 OF 3
REC 3 OF 3
/*
//SYSOUT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
And you'll get this output
You'll see the same SYSIN data repeated three times.
For a 'C' program this reference in the IBM documentation for the C Compiler provides some hints about rewinding.
To open an in-stream data set, call the fopen() or freopen() library
function and specify the ddname of the data set. You can open an
in-stream data set only for reading. Specifying any of the update,
write, or append modes fails. Once you have opened an in-stream data
set, you cannot acquire or change the file position except by
rewinding. This means that calls to the fseek(), ftell(), fgetpos(),
and fsetpos() for in-stream data sets fail. Calling rewind() causes
z/OS XL C/C++ to reopen the file, leaving the file position at the
beginning.
What you're looking for is possible but the implementation is language dependent.
For CDA Authentication The EMV terminal a GENERATE AC command like
80 AE P1 00 LC DATA 00
CLA = 80
INS = AE
P1 = ?
P2 = 00
LC = ?
DATA = ?
LE = 00
Where do the parameters P1, LC and Data come from?
P1 defines the type of cryptogram you expect the chip to generate for you. It also has bit to specify the data has to be responded inside a CDA jacket. Refer the below part from EMVCo book 3.
So P1 = 0x00 will mean you expect an AAC,
0x80 for ARQC and
0x40 for TC
Turn on bit 5, and you get the data inside a certificate.
I hope you understand that not always you will get the expected cryptogram type back from Card. It can be in the order TC > ARQC > AC. When requesting TC, you can expect TC, ARQC or AC. When ARQC is requested you can get ARQC or AAC, but not TC. When AAC is requested, it is always AAC and not TC or ARQC.
I am using an ATmega32 to do interrupt
when i trying to do driver of external interrupt 0 , faced me a problem
Interrupt Vectors Table in ATmega32
Interrupt Vectors code in ISR(vector)
In iom32.h code , we see that ((INT0_vect " _VECTOR(1) ")) it's number 1 but in data sheet we see that the number is 2 , why ?
The datasheet starts numbering with the reset vector. But there is no need for an explicit define (like RESET_vect) for the reset vector, since it will not be used in conjunction with ISR(). So in the header/AVRGCC implementation it is omitted.
If you compile this
ISR(INT0_vect) { }
and look at the interrupt vector table
00000000 <__vectors>:
0: 0c 94 46 00 jmp 0x8c ; 0x8c <__ctors_end>
4: 0c 94 5f 00 jmp 0xbe ; 0xbe <__vector_1>
you can see that __vector_1 is placed at byte address 4, which corresponds to the word address 2 from the data sheet.
I am trying to port a program which queries an LDAP server from Perl to Go, and with the Go version I am receiving a response that the filter is malformed:
00000057: LdapErr: DSID-0C0C0968, comment: The server was unable to decode a search request filter, data 0, v1db1\x00
I have used tcpdump to capture the data transmitted to the server with both the Perl and Go versions of my program, and have found that they are sending slightly different filter packets. This question is not about any possible bugs in the Go program, but simply about understanding the contents of the LDAP filter packets.
The encoded filter is:
(objectClass=*)
And the Perl-generated packet (which the server likes) looks like this:
ASCII . . o b j e c t C l a s s
Hex 87 0b 6f 62 6a 65 63 74 43 6c 61 73 73
Byte# 0 1 2 3 4 5 6 7 8 9 10 11 12
The Go-generated packet (which the server doesn't like) looks like this:
ASCII . . . . o b j e c t C l a s s
Hex a7 0d 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73
Byte# 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
This is my own breakdown of the packets:
##Byte 0: Tag
When I dissect Byte 0 from both packets, I see they are identical, except for the Primitive/Constructed bit, which is set to Primitive in the Perl version, and Constructed in the Go version. See DER encoding for details.
Bit# 87 6 54321
Perl 10 0 00111
Go 10 1 00111
Bits 87: In both packets, 10 = Context Specific
Bit 6: In the Perl version 0 = Primitive, in the Go version 1 = Constructed
Bits 54321: 00111 = 7 = Object descriptor
##Byte 1: Length
11 bytes for the Perl version, 13 for the Go version
##Bytes 2-3 for the Go version
Byte 2: Tag 04: Substring Filter (See section 4.5.1 of RFC 4511)
Byte 3: Length of 11 bytes
##Remainder: Payload
For both packets this is simply the ASCII text objectClass
My reading of RFC 4511 section 4.5.1 suggests that the Go version is "more" correct, yet the Perl version is the one that works with the server. What gives?
Wireshark is able to parse both packets, and interprets them both equally.
The Perl version is correct, and the Go version is incorrect.
As you point out, RFC 4511 section 4.5.1 specifies encoding for the filter elements, like:
Filter ::= CHOICE {
and [0] SET SIZE (1..MAX) OF filter Filter,
or [1] SET SIZE (1..MAX) OF filter Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion,
... }
And in this case, the relevant portion is:
present [7] AttributeDescription,
The AttributeDescription element is defined in section 4.1.4 of the same specification:
AttributeDescription ::= LDAPString
-- Constrained to <attributedescription>
-- [RFC4512]
And from section 4.1.2:
LDAPString ::= OCTET STRING -- UTF-8 encoded,
-- [ISO10646] characters
So this means that the present filter component is an octet string, which is a primitive element. Go is incorrectly converting it to a constructed element, and the directory server is correctly rejecting that malformed request.