Why not use the built in PCSC libraries in Windows?
http://msdn.microsoft.com/en-us/library/windows/desktop/aa380141(v=vs.85).aspx.
This is the same API as in PCSC lite.
Sent from my iPad
On Feb 10, 2014, at 12:36 PM, Sergio NNX sfhac...@hotmail.com wrote:
Hi all,
I'm after
I don't know the actual answer. In practice, there are only a few ways to make
this work.
1) prefix the pin field with a length byte.
2) pad the pin with some value that can't be input as the pin (e.g. for ascii
pins, use FF as the padding value).
3) truncate the pin to the appropriate length
I don't know the actual answer. In practice, there are only a few ways to make
this work.
1) prefix the pin field with a length byte.
2) pad the pin with some value that can't be input as the pin (e.g. for ascii
pins, use FF as the padding value).
3) truncate the pin to the appropriate length
At 03:45 PM 7/3/2013, Ludovic Rousseau wrote:
2013/7/3 MURILO COSTA murilo.dua...@unitau.com.br:
I thought that maybe can be a Java problem, do you know some software to do
this kind of test (parallelism) ? I'll check if pcsc-tools can do that...
I guess it is a javax.smartcardio limitation.
At 03:45 PM 7/3/2013, Ludovic Rousseau wrote:
2013/7/3 MURILO COSTA murilo.dua...@unitau.com.br:
I thought that maybe can be a Java problem, do you know some software to do
this kind of test (parallelism) ? I'll check if pcsc-tools can do that...
I guess it is a javax.smartcardio limitation.
The first thing I'd do is take a look at which versions of the ccid and
pcsclite packages you have on your system. You may need to update those
substantially. Also, take a look at the logs for the pcscd - see if you even
got that far.
Mike
At 02:56 PM 1/24/2013, Wolfgang Korn wrote:
Hi
The first thing I'd do is take a look at which versions of the ccid and
pcsclite packages you have on your system. You may need to update those
substantially. Also, take a look at the logs for the pcscd - see if you even
got that far.
Mike
At 02:56 PM 1/24/2013, Wolfgang Korn wrote:
Hi
I don't use Chrome, but I think it supports PKCS11. I'd try that approach with
the musclecard PKCS11 implementation and the CAC and coolkey plugins.
Mike
At 09:08 PM 6/24/2012, Howdy Doody wrote:
Hello,
I have been unable to find an answer to this anywhere else, but is there
any way, at all,
At 08:02 AM 4/30/2012, =?iso-8859-2?B?TW9sbuFyIFZpbmNl?= wrote:
Dear all,
I am trying to use the muscle applet to encrypt a piece of data using a RSA
key pair.
So far I have no luck, almost every version of the applet that I tried fails
at the cipher final step, sometimes with
In RSA you encrypt with the public key, decrypt with the private key, sign with
the private key and verify with the public key. You can't - as you appear to
be trying to do - encrypt with the private key.
Unfortunately, what you wrote below gives no useful information to help you as
it
Comments/questions below.
At 05:18 AM 4/23/2012, Martin Paljak wrote:
Hello,
On Fri, Apr 13, 2012 at 22:05, Jean-Michel Pouré - GOOZE
jmpo...@gooze.eu wrote:
Le jeudi 12 avril 2012 à 14:33 +0800, shilpa.shi...@shell.com a écrit :
We are using redhat 5.7and gemalto 64k v2c smartcard.Please
At 02:12 PM 4/23/2012, Martin Paljak wrote:
On Mon, Apr 23, 2012 at 20:45, Michael StJohns mstjo...@comcast.net wrote:
In practice the only common open source applet, MuscleApplet,
There's also CoolKey derived from Muscle as well as a few open versions of
the PIV II applet.
I'm aware
Parsing the ATR, this might be a YPSID S3 smart card.(The historical bytes
encode to YPSID03 with a card status of 0x7f).
If its either an S2 or S3 ypsID it is a javacard.
Mike
At 03:03 PM 8/12/2011, Marcelo Aloisio da Silva wrote:
Hi,
Please, I need help. I have a card with no
Parsing the ATR, this might be a YPSID S3 smart card.(The historical bytes
encode to YPSID03 with a card status of 0x7f).
If its either an S2 or S3 ypsID it is a javacard.
Mike
At 03:03 PM 8/12/2011, Marcelo Aloisio da Silva wrote:
Hi,
Please, I need help. I have a card with no
At 12:46 PM 3/25/2011, Andreas Jellinghaus wrote:
And is any such card sold in a state where you can influence the basic
settings such as atr or real-uid vs. random uid etc? And sold in quantities
like one, two or three cards (for testing)? At reasonable prices?
The ATR - at least the historical
At 12:46 PM 3/25/2011, Andreas Jellinghaus wrote:
And is any such card sold in a state where you can influence the basic
settings such as atr or real-uid vs. random uid etc? And sold in quantities
like one, two or three cards (for testing)? At reasonable prices?
The ATR - at least the historical
At 06:00 AM 3/25/2011, Sébastien Lorquet wrote:
You're talking about not initialized cards. First, it's near impossible to
find cards in this state,
If you buy them in enough quantity, say north of 1000 then its is possible to
buy them from the manufacturer. Generally the form you get them
At 06:00 AM 3/25/2011, Sébastien Lorquet wrote:
You're talking about not initialized cards. First, it's near impossible to
find cards in this state,
If you buy them in enough quantity, say north of 1000 then its is possible to
buy them from the manufacturer. Generally the form you get them
At 09:33 AM 3/25/2011, Karsten Ohme wrote:
For buying cards I would rather not mention special web shops. This
would be not fair for some merchants
I'd actually like to second the request. And provide a link for web shops to
submit information (specific link to order card type N). As long as
At 09:33 AM 3/25/2011, Karsten Ohme wrote:
For buying cards I would rather not mention special web shops. This
would be not fair for some merchants
I'd actually like to second the request. And provide a link for web shops to
submit information (specific link to order card type N). As long as
At 04:14 AM 12/14/2010, Sébastien Lorquet wrote:
I don't believe *javacard* itself , or any current javacard platform, provides
support for 4096 bits RSA.
javacard supplies constants for the bit length of RSA up to I think 2048, but a
card can support longer sizes. Depends on the card. I
At 04:14 AM 12/14/2010, Sébastien Lorquet wrote:
I don't believe *javacard* itself , or any current javacard platform, provides
support for 4096 bits RSA.
javacard supplies constants for the bit length of RSA up to I think 2048, but a
card can support longer sizes. Depends on the card. I
If you run into problems on Fedora, login as root and do setenforce
permissive - this will continue to log the errors, but allow you to run...
Mike
At 04:07 PM 9/4/2010, Ludovic Rousseau wrote:
2010/9/4 Michael StJohns mstjo...@comcast.net:
Hi -
Hello,
It wasn't clear from your emails
If you run into problems on Fedora, login as root and do setenforce
permissive - this will continue to log the errors, but allow you to run...
Mike
At 04:07 PM 9/4/2010, Ludovic Rousseau wrote:
2010/9/4 Michael StJohns mstjo...@comcast.net:
Hi -
Hello,
It wasn't clear from your emails
At 06:11 AM 6/22/2010, emmanuel DELOGET wrote:
I suggest you give a look to the Smartcard Handbook
(http://www.amazon.com/Smart-Card-Handbook-Wolfgang-Rankl/dp/0470856688/ref=dp_ob_title_bk),
in particular chapter 6. It's a bit pricey but it's a very good book (saved
me tons of time when I had to
At 06:11 AM 6/22/2010, emmanuel DELOGET wrote:
I suggest you give a look to the Smartcard Handbook
(http://www.amazon.com/Smart-Card-Handbook-Wolfgang-Rankl/dp/0470856688/ref=dp_ob_title_bk),
in particular chapter 6. It's a bit pricey but it's a very good book (saved
me tons of time when I had to
http://pdf1.alldatasheet.com/datasheet-pdf/view/168859/SIEMENS/SLE4442/+047J5-UOGDL.OudVPKCwDw+/datasheet.pdf
has the data sheet for the card. This looks like a generic password protected
memory card. So mostly 7816-4 and 7816-6 should apply. However, it looks like
the 4442 has a 3 byte
http://pdf1.alldatasheet.com/datasheet-pdf/view/168859/SIEMENS/SLE4442/+047J5-UOGDL.OudVPKCwDw+/datasheet.pdf
has the data sheet for the card. This looks like a generic password protected
memory card. So mostly 7816-4 and 7816-6 should apply. However, it looks like
the 4442 has a 3 byte
Try running the compile with -O2 -Wall --pedantic and report the errors back
to identify the specific place where this might be an issue.
Mike
At 09:24 PM 1/1/2010, Han Hartgers wrote:
Dear List and Dr. Rousseau,
I can confirm that my problem is the same as Debian bug #502947.
I must say
Try running the compile with -O2 -Wall --pedantic and report the errors back
to identify the specific place where this might be an issue.
Mike
At 09:24 PM 1/1/2010, Han Hartgers wrote:
Dear List and Dr. Rousseau,
I can confirm that my problem is the same as Debian bug #502947.
I must say
Isn't there a details tab on the property page for the device? What you want
to be able to try this with PCSCD are the hardware (vendor and product) ids. I
don't have a 2K machine around any more, but that's the case with my XP
machine. For example my built in smart card reader has
Isn't there a details tab on the property page for the device? What you want
to be able to try this with PCSCD are the hardware (vendor and product) ids. I
don't have a 2K machine around any more, but that's the case with my XP
machine. For example my built in smart card reader has
The Ricoh is the card reader for things like SD and other flash memories, it
probably has nothing to do with the smart card reader.
Looking at the HP website for drivers for this laptop - specifically looking at
the drivers for Vista Enterprise 32bit reveals a driver for an SCRXXX card
reader
The Ricoh is the card reader for things like SD and other flash memories, it
probably has nothing to do with the smart card reader.
Looking at the HP website for drivers for this laptop - specifically looking at
the drivers for Vista Enterprise 32bit reveals a driver for an SCRXXX card
reader
specific driver.
Later, Mike
At 02:05 PM 12/17/2009, Martin Paljak wrote:
On 17.12.2009, at 20:17, Michael StJohns wrote:
The Ricoh is the card reader for things like SD and other flash memories, it
probably has nothing to do with the smart card reader.
Not correct. See the chip description
specific driver.
Later, Mike
At 02:05 PM 12/17/2009, Martin Paljak wrote:
On 17.12.2009, at 20:17, Michael StJohns wrote:
The Ricoh is the card reader for things like SD and other flash memories, it
probably has nothing to do with the smart card reader.
Not correct. See the chip description
Mostly, you can use any JDK to do the build, but you need to add the
target=1.4 or target=1.5 to the javac task in the buildapplet.xml file
Which target depends on which version of the javacard SDK you're using. So
use the current JDK that comes with Ubuntu and it should work fine.
Mike
Mostly, you can use any JDK to do the build, but you need to add the
target=1.4 or target=1.5 to the javac task in the buildapplet.xml file
Which target depends on which version of the javacard SDK you're using. So
use the current JDK that comes with Ubuntu and it should work fine.
Mike
The USB vendor/product id probably changed between versions. There's an
Info.plist file associated with the CCID driver that you can update. Use
lsusb with the token inserted and you should be able to capture the changed
id.
http://pcsclite.alioth.debian.org/ccid.html#CCID_compliant
Dr
The USB vendor/product id probably changed between versions. There's an
Info.plist file associated with the CCID driver that you can update. Use
lsusb with the token inserted and you should be able to capture the changed
id.
http://pcsclite.alioth.debian.org/ccid.html#CCID_compliant
Dr
The answer is it depends - on the actual type of card and how it was
initialized. If its a global platform (www.globalplatform.com) card for
example, you might be able to retrieve the card personalization data using a
specific Get Data call.
If you post the ATR for your card here, chances are
At 01:50 PM 9/11/2009, Nagy Gabor wrote:
2009. 09. 11, péntek keltezéssel 13.37-kor Michael StJohns ezt Ãrta:
The answer is it depends - on the actual type of card and how it was
initialized. If its a global platform (www.globalplatform.com) card for
example, you might be able to retrieve
At 01:50 PM 9/11/2009, Nagy Gabor wrote:
2009. 09. 11, péntek keltezéssel 13.37-kor Michael StJohns ezt Ãrta:
The answer is it depends - on the actual type of card and how it was
initialized. If its a global platform (www.globalplatform.com) card for
example, you might be able to retrieve
At 09:12 AM 6/17/2009, Daniel Benoy wrote:
On Wed, 2009-06-17 at 00:11 -0400, Michael StJohns wrote:
At 11:33 PM 6/16/2009, Daniel Benoy wrote:
So the card user could put an applet on the card that used up all the
space, and that would be bad for the card issuer? Are there any other
reasons
The card body (the plastic carrier) can be one of several configurations. The
most common for javacards with an RF capability seems to be Mifare. But there
are companies that can provide cards or card bodies that have the more normal
prox card RF capabilities (either instead of or in addition
At 12:51 PM 6/17/2009, Daniel Benoy wrote:
Aren't you able to also break the card by failing to open a secure channel to
the issuer domain a certain number of times?
Wouldn't you think the issuer might consider that you were trying to hack the
card if that happened? There's no legitimate
At 12:51 PM 6/17/2009, Daniel Benoy wrote:
Aren't you able to also break the card by failing to open a secure channel to
the issuer domain a certain number of times?
Wouldn't you think the issuer might consider that you were trying to hack the
card if that happened? There's no legitimate
At 11:33 PM 6/16/2009, Daniel Benoy wrote:
So the card user could put an applet on the card that used up all the
space, and that would be bad for the card issuer? Are there any other
reasons a business would keep their key secret?
Say you insert your card into a hacked machine. Hacked machine
At 11:33 PM 6/16/2009, Daniel Benoy wrote:
So the card user could put an applet on the card that used up all the
space, and that would be bad for the card issuer? Are there any other
reasons a business would keep their key secret?
Say you insert your card into a hacked machine. Hacked machine
Some card manufacturers do provide some card specific extra mechanism which do
raw signatures.
E.g. ALG_ECDSA_NOHASH.
Ask your card provider or reseller.
Mike
At 12:23 PM 6/11/2009, s.ferey wrote:
erbalibera erbalibera a écrit :
is It the same for dsa with sha-1? If yes wich provider is
OK - I think I see one more possibility for the problem. If you're using
padding, then the plain text MUST be shorter than the key length to allow for
the addition of padding. Reduce the cipher text by 20 octets and try again.
Mike
At 08:40 AM 5/1/2009, jose85 wrote:
Hello,
Thanks for
OK - I think I see one more possibility for the problem. If you're using
padding, then the plain text MUST be shorter than the key length to allow for
the addition of padding. Reduce the cipher text by 20 octets and try again.
Mike
At 08:40 AM 5/1/2009, jose85 wrote:
Hello,
Thanks for
Sorry - I forgot that from your original posts.
I do suggest exporting the private key and doing a manual decrypt to find out
how the card encrypts the data.
byte[] ciphertext (after the card encrypts your data)
byte[] privateModulus
byte[] privateExponent
BigInteger cipherBig = new
The padding block type 0 was deprecated after PKCS1 v1.5 and not even mentioned
in the current version. The JC API also changed along the way to reflect this
deprecation.
If you go back and look at the API document for JC2.1 you'll see that, unlike
later versions, it doesn't mention the
The padding block type 0 was deprecated after PKCS1 v1.5 and not even mentioned
in the current version. The JC API also changed along the way to reflect this
deprecation.
If you go back and look at the API document for JC2.1 you'll see that, unlike
later versions, it doesn't mention the
According to PKCS1 - section 7.2 and 7.2.1 the recommendation is to generate a
new random padding string for each encryption operation. The java
implementation is following this recommendation while the card probably isn't.
What I'd recommend doing is generating an encryption on the card
According to PKCS1 - section 7.2 and 7.2.1 the recommendation is to generate a
new random padding string for each encryption operation. The java
implementation is following this recommendation while the card probably isn't.
What I'd recommend doing is generating an encryption on the card
PROTECTED]
When replying, please edit your Subject line so it is more specific
than Re: Contents of Muscle digest...
Today's Topics:
1. Re: Re: Problem Formatting Card and other Issues(Michael,
StJohns) (Michael StJohns) (Bram Cymet)
2. Signing Problems (Bram Cymet
PROTECTED]
When replying, please edit your Subject line so it is more specific
than Re: Contents of Muscle digest...
Today's Topics:
1. Re: Re: Problem Formatting Card and other Issues(Michael,
StJohns) (Michael StJohns) (Bram Cymet)
2. Signing Problems (Bram Cymet
When you did the format, did you accept the default key muscletool offered or
did you input one of your own? The key isn't really a key per se, but a pin
used to check and see if you're authorized to format the applet. The key is
built in to the applet and can't be changed unless you
When you did the format, did you accept the default key muscletool offered or
did you input one of your own? The key isn't really a key per se, but a pin
used to check and see if you're authorized to format the applet. The key is
built in to the applet and can't be changed unless you
Hi Bram -
Once you load the applet onto the card you have to initialize it. That sets up
the PINs and other features including memory size.
Mike
At 03:15 PM 10/29/2008, Bram Cymet wrote:
Hi,
I am using Atheca IDProtext Dual cards and I am able load the muscle app
onto the card without any
Hi Bram -
Once you load the applet onto the card you have to initialize it. That sets up
the PINs and other features including memory size.
Mike
At 03:15 PM 10/29/2008, Bram Cymet wrote:
Hi,
I am using Atheca IDProtext Dual cards and I am able load the muscle app
onto the card without any
Sorry - I missed your comment about formatting.. that's what you do need to do
- what I called initialize. Sounds like you've got library mismatches. Did
you build muscleTool from scratch or did you use a prebuild from somewhere?
have you tried building from scratch?
Mike
At 03:15 PM
Hi Bram -
The other key parameter you need to consider - performance. How many
signatures per second do you need?
I've had good luck with the JCOP41 (72k) cards. They're triple interface -
Wireless, ISO7816 and USB. You can punch them out of the card and place them
in a USB dongle. USA
Hi Bram -
The other key parameter you need to consider - performance. How many
signatures per second do you need?
I've had good luck with the JCOP41 (72k) cards. They're triple interface -
Wireless, ISO7816 and USB. You can punch them out of the card and place them
in a USB dongle. USA
- Original Message -
From: mailto:[EMAIL PROTECTED]Michael StJohns
To: mailto:muscle@lists.musclecard.comMUSCLE
Sent: Saturday, April 19, 2008 6:28 PM
Subject: Re: [Muscle] SunPCSC
Have you tried just using the default provider?
E.g. Terminal Factory tf = TerminalFactory.getDefault
- Original Message -
From: mailto:[EMAIL PROTECTED]Michael StJohns
To: mailto:muscle@lists.musclecard.comMUSCLE
Sent: Saturday, April 19, 2008 6:28 PM
Subject: Re: [Muscle] SunPCSC
Have you tried just using the default provider?
E.g. Terminal Factory tf = TerminalFactory.getDefault
Have you tried just using the default provider?
E.g. Terminal Factory tf = TerminalFactory.getDefault();
I tried your code on winxp with SP 2 and java 1.6_04 and it worked fine. So
its probably not java, its your machine.
I'd try printing out your exceptions stack trace to try and find out
Have you tried running the applet against the cref simulator included in the
javacard dev environment 2.2.1?The -z option prints a pile of resource info
including most of what you're looking for to size the applet memory
requirements.
Mike
At 01:29 PM 3/19/2008, kamal kumar wrote:
HI all,
Have you tried running the applet against the cref simulator included in the
javacard dev environment 2.2.1?The -z option prints a pile of resource info
including most of what you're looking for to size the applet memory
requirements.
Mike
At 01:29 PM 3/19/2008, kamal kumar wrote:
HI all,
I'm writing a set of javacard applets and one of the pieces of data I needed
was what AID/RID to select for my applets. I *really* didn't want to go
through the hassle of registering with whatever body gives out RIDs.
A little research revealed that AIDs starting with 'F' were reserved for
Amanda -
Using muscletools do
1) Log yourself in (verify)
2) Do a listkeys
3) Try and do the signature again.
Post the output of the above here.
There are a number of possibilities - rather than randomly guessing, perhaps we
can help you interpret the output.
At 12:26 PM 3/3/2008,
At 19:03 2/27/2008, Karsten Ohme wrote:
I'm afraid, GPShell will not not work. Because it might be impossible.
Actually I see no reason why a card could not be rest to the default key set
and empty state. If all data is zeroed out, nothing should happen. But maybe
there a some security problems
At 19:03 2/27/2008, Karsten Ohme wrote:
I'm afraid, GPShell will not not work. Because it might be impossible.
Actually I see no reason why a card could not be rest to the default key set
and empty state. If all data is zeroed out, nothing should happen. But maybe
there a some security problems
If I understand this, you want to use a public RSA key to encrypt key material
for export?
The applet doesn't support it, but you could extend the applet (and the
supporting code) to do this...
Look at the code for MSC_ExportKey as a starting point on the library side and
at the corresponding
Complains or changes its mechanism to what's reported?
I'm off doing a few other things right now - I should be able to get back to
this early next week... thanks for the changes! If you do have a compiled
version, I'd prefer that. I haven't got GlobalPlatform set up as one of my
compile
Firefox does this as well. I don't know how iceweasel works - but you can
disable this in Firefox by going into the options and deleting (unconfiguring)
the PKCS11 module that talks to musclecards.
At 11:42 1/17/2008, Amanda Ortega wrote:
Hi!
I solved this problem quitting the browser
$ !!
./GPShell listgp211.txt
mode_211
enable_trace
establish_context
card_connect
* reader name Gemplus GemPC Express 0
select -AID a300
-- 00A4040008A300
-- 6F108408A300A5049F6501FF9000
open_sc -security 1 -keyind 0 -keyver 0 -mac_key
$ !!
./GPShell listgp211.txt
mode_211
enable_trace
establish_context
card_connect
* reader name Gemplus GemPC Express 0
select -AID a300
-- 00A4040008A300
-- 6F108408A300A5049F6501FF9000
open_sc -security 1 -keyind 0 -keyver 0 -mac_key
report an error, if explicit protocol selection does not match the
protocol supported by the card.
I think that's the right answer.
Andreas
Michael StJohns schrieb:
Here's a strange one. I've got two different JCOP cards - JCOP41 and JCOP31
- both NXP based. Both report EXACTLY the same global
report an error, if explicit protocol selection does not match the
protocol supported by the card.
I think that's the right answer.
Andreas
Michael StJohns schrieb:
Here's a strange one. I've got two different JCOP cards - JCOP41 and JCOP31
- both NXP based. Both report EXACTLY the same global
Here's a strange one. I've got two different JCOP cards - JCOP41 and JCOP31 -
both NXP based. Both report EXACTLY the same global platform configuration
data (e.g. a response to a 00 CA 00 60 query) and indicate support for SCP
02.
When I use GPShell to look at the cards, mode_211 works
I have this suspicion that the tools are not compatible with JDK1.6. Maybe try
using 1.5 as your java.
At 07:50 7/20/2007, Alexej Muehlberg wrote:
Gina,
what JCOP Tools version are you using? Can post or send me a bug report? Maybe
it is faster to provide you a workaround.. We have a
in that version
of the applet - there is at least one way to cause the card to lose track of
key objects so you can't delete them and you lose the space. I'll pass those
along if you'd like once I find them.
Thanks - Mike
At 14:40 6/26/2007, Karsten Ohme wrote:
Michael StJohns schrieb:
I
Yes, I know that. The ASN1 encoded object below is what pops out. Of the 5
sub objects I was able to find OID descriptions for 3. For one of them (tag
06), I recognize the prefix (Sun), but can't find the details for this branch
of the OID tree (e.g what version of Java Card for example). I
Anyone know what OID 1.3.656.840.100.2.1.3 maps to?
I've been playing around with a JCOP41v221 card and I was able to dump the card
information file (GET DATA command with tag 0x66). What I get is an ASN1
encoded blob. Dumping the blob, I get the values below.I was able to find
the
I've been using JCOP41 cards based on the NXP chip with reasonable results.
The card manager is global platform compliant. usasmartcard.com has them. The
41 cards have DES, RSA and EC algorithms on them.
It took me a while to get the incantations correct, but I'm using GPShell to
load the
I've got a few of the NXP/Phillips JCOP41 cards. The cards are designed to do
e-gate style USB connection so I dumped one of them into one of my old e-gate
readers and voila - Windows recognized the card, loaded a USB driver and then
nothing.
The various tools I've tried all seem to say the
I was having this problem with Mozilla 2.0 on Win XP. I got the libraries you
asked for, updated my copies to merge in the changes between 1.1.5 and 1.1.6,
and still couldn't make it work.
I eventually found the musclecard stuff (ohme's 2.0 source) was referring to
the win 8.0 runtime
for Elliptic Curve, the you
reference don't.
Mike
At 02:05 5/30/2007, Ludovic Rousseau wrote:
On 24/05/07, Michael StJohns [EMAIL PROTECTED] wrote:
I downloaded, compiled and installed the applet on a JCOP41 card and it works
fine.
But while I was reading the code, I noticed a possible problem
I downloaded, compiled and installed the applet on a JCOP41 card and it works
fine.
But while I was reading the code, I noticed a possible problem in CardEdge.src.
Near the beginning is: private final static short RESERVED_OBJECT_CLA_MASK =
(short) 0xFFFD;
That's used elsewhere to keep
92 matches
Mail list logo
