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.
Related
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'
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 redirect ofp_packet_in packet among multiple controllers. For example, suppose there are two controllers c1,c2 and one switch s1. s1 is assigned to c1. Now, c1 receives a Packet_In from switch s1. Generally, s1 should dispose of this Packet_In. What I am trying to do is to send this Packet_In to c2 and let c2 process this Packet_In.
I am trying to implement my idea by POX, but I got some mistakes.
This is the code of c1, only _handle_packet_in is shown:
def _handle_PacketIn(self, event):
log.debug("Switch %s has a PacketIn: [port: %d, ...]", event.dpid, event.port)
self._redirect_packet(event)
def _redirect_packet(self, event):
log.debug("Send packet to 6634!")
TCP_IP = '10.0.2.15'
TCP_PORT = 6634
BUFFER_SIZE = 1024
packet = event.ofp
# I attach all the payload of OpenFlow Packet_In to the new packet
MESSAGE = packet.pack()
# MESSAGE = MESSAGE + 'Hello world'
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((TCP_IP, TCP_PORT))
s.send(MESSAGE)
# s.close()
Then I start Mininet and build the topology. (Here the topology has little difference with the formal description, however, it is clear and modified from Mininet example controllers2.py)
from mininet.net import Mininet
from mininet.node import Controller, OVSSwitch
from mininet.cli import CLI
from mininet.log import setLogLevel
from mininet.node import RemoteController
def multiControllerNet():
"Create a network from semi-scratch with multiple controllers."
net = Mininet( controller=Controller, switch=OVSSwitch, autoSetMacs=True )
print "*** Creating (reference) controllers"
# c1 = net.addController( 'c1', port=6633 )
# c2 = net.addController( 'c2', port=6634 )
c1 = net.addController('c1', controller=RemoteController, ip='10.0.2.15', port=6633)
c2 = net.addController('c2', controller=RemoteController, ip='10.0.2.15', port=6634)
print "*** Creating switches"
s1 = net.addSwitch( 's1' )
s2 = net.addSwitch( 's2' )
print "*** Creating hosts"
hosts1 = [ net.addHost( 'h%d' % n ) for n in 3, 4 ]
hosts2 = [ net.addHost( 'h%d' % n ) for n in 5, 6 ]
print "*** Creating links"
for h in hosts1:
net.addLink( s1, h )
for h in hosts2:
net.addLink( s2, h )
net.addLink( s1, s2 )
print "*** Starting network"
net.build()
# c1.start()
c2.start()
s1.start( [ c1 ] )
# s1.start([c2])
s2.start( [ c2 ] )
# s2.start([c2])
# print "*** Testing network"
# net.pingAll()
print "*** Running CLI"
CLI( net )
print "*** Stopping network"
net.stop()
if __name__ == '__main__':
setLogLevel( 'info' ) # for CLI output
multiControllerNet()
Then, I start two controllers at my host with different ports, 6633, 6634. Open c1:
../pox.py openflow.of_01 --port=6633 --address=10.0.2.15 openflow_test log.level --DEBUG
and, open c2
../pox.py openflow.of_01 --port=6634 --address=10.0.2.15 openflow_test_2 log.level --DEBUG
c1 has only the _handle_packet_in handler which is shown above. c2 has no function.
I try to ping between h3 (controlled by c1) to h5 (controller by c2), in order to trigger _handle_packet_in handler.
I use wireshark to capture the of_packet_in packet, and the new redirect packet
of_packet_in packet:
redirect packet:
It is clear that they have the same payload (OpenFlow packet).
However, c2 doesn't accept this packet, and warn that this is dummy OpenFlowNexus. This is the error:
I guess, even if c1 sends a legal OpenFlow of_packet_in to c2, c2 has no idea about "who is c1", for c1 has not registered to c1 using OpenFlow of_hello, of_features_request,.... Therefore, c2 discard the OpenFlow of_packet_in sent by c1, and say dummy.
I only want to let c2 process the Packet_In redirected by c1. In this way, c2 can calculate and install table entries for table-miss event happened in s1.
Maybe I can use other controllers, like floodlight, ONOS..., to solve this problem. Maybe this problem cannot be solved. Thank you for sharing your idea, best wishes.
I am using POX 0.2.0 (carp)
You connect c1 to c2 as if c1 is a switch and you expect c2 to treat c1 like that. However, c1 did no represent itself like this. In fact, c1 did not introduce itself to c2 in no way. Each switch that connects to a controller follows a certain identification protocol and you can see that happen in ConnectionUp handler. c1 does not trigger this handler at c2.
c1 can identify itself as a switch to c2 and then redirect packets to it. However, to my mind, this is too cumbersome. I would recommend that c1 connect to c2 out-of-band and communicate with c2 in their own protocol(rules). For example, c2 waits for a connection on a different port. When c1 connects, c2 waits for redirected packets. c1 redirects a packet with the required context to c2, and c2 decides on action upon receiving the packet and the required context.
i seem to always get incorrect output when decoding this base64 string in vb.net ( i think its base64? it really looks like it )
im using the frombase64string function
and i did it like this
Dim b64str = "0DDQQL3uAikQBgAAc4cqK4WnSQBg4SAgExEAAF3BAmAILYojRgkBhUrBAgEDRw=="
Dim i As String = System.Text.Encoding.Unicode.GetString(Convert.FromBase64String(b64str))
MsgBox(i)
but i always get this output
バ䃐⤂ؐ
that doesn't seem right
0DDQQL3uAikQBgAAc4cqK4WnSQBg4SAgExEAAF3BAmAILYojRgkBhUrBAgEDRw==
It looks like Base64, the length is a correct size, the characters belong to the Base64 character set and the trailing "==" is reasonable. Of course it might not be a Base64 encoding.
Base64 decoding results in:
D0 30 D0 40 BD EE 02 29 10 06 00 00 73 87 2A 2B 85 A7 49 00 60 E1 20 20 13 11 00 00 5D C1 02 60 08 2D 8A 23 46 09 01 85 4A C1 02 01 03 47
Now the problem, this is not a character string, it is an array of 8-bit bytes. Thus it can not be displayed as characters. The 0x00 bytes will signal the end of a string to the print method and the no-representable characters may be ignored, displayed with special characters or multiple bytes may display as must-byte unicode characters. The only guaranteed and usual display is in hexadecimal as above.
That String can be virtually anything. It might be the result of an encryption algorithm, like sha*. Your mistake is that you assume that it must be base64 because it might be.
It is a valid observation that it might be base64, so it was a perfectly valid thing to run that function, but it is you who has to determine whether based on the results it is base64 or something else, based on particular logic, which was not described in the question.
I am facing an issue with my flat file. The BAdI is processing the header data as the body of the flat file. Due to this . The TIMEID, which is conditioned to be an year belonging to 'Q1', is giving the error. If I replace the TIME label with 2014.Q1 (which belongs to Q1), then it works fine, but if I use the label “TIMEID” in the header data, it gets evaluated, and gives an error “time member TIMEID does not belong to Q1”. This also rejects all the subsequent records. This happens regardless of whether HEADER in the transformation file is labeled as YES (with SKIP=1) or NO.
Due to this, the “cl_ujk_query=>query()” function is not returning any data.
Following is the flat file (Cis for header data, and R is for the records, both of which are valid):
______________________________________________________________________
c1 c2 c3 c4 c5 TIMEID c7 c8 c8 c9
______________________________________________________________________
r11 r12 r13 r14 r15 2014.Q1 r17 r18 r19 r20
r21 r22 r23 r24 r25 2013.Q1 r27 r28 r29 r30
_____________________________________________________________________
Following is the Transformation File:
_________________________________________________________________________
***OPTIONS
FORMAT = DELIMITED
HEADER = YES
DELIMITER = ,
SKIP = 1
SKIPIF =
VALIDATERECORDS=YES
CREDITPOSITIVE=YES
MAXREJECTCOUNT= -1
ROUNDAMOUNT=
STARTROUTINE=ZNAME_TIME
*MAPPING
A=*COL(1)
B=*STR(OC_) + *COL(8)
TIME=*COL(6)
D=*STR(NOBUYER)
E=*STR(CC)
F=*STR(INPUT)
G=*COL(5)
H=*COL(2)
I=*COL(4)
J=*STR(NO_J)
K=*COL(7)
*CONVERSION
**
________________________________________________________________________
You have to change the header = NO in the transformation file .