Closed kaoh closed 4 years ago
Hi,
Well, I guess it it is some memory leak. I do not have such a card, so I can analyze the code, but maybe it is hard to get it. If you have the core you can sent it to me by email.
If it is a JavaCard it should be possible to install the MuscleCard applet on it, if gpshell works.
Original comment by: kaoh
I've e-mailed you the core dump.
Also, does the output I supplied above give no indication at all of whether it's actually a JavaCard, and what may have caused the segfault?
Original comment by: *anonymous
Really? I have received no mail.
It is a Java Card. The mutual authentication is successful. After this something happens. Can can also enable debugging: "set GLOBALPLATFORM_DEBUG=1" and there should be a log file in the temp dirtectory.
Original comment by: kaoh
Stop trying to use this card. The mutual authentication is not successful. The card gets locked forever after 3 up more tries. the INITIALIZE UPDATE command causes an error in the code.
I you have already reached this limit, be careful. If you have a try left use the debug feature:
If you experience problems a DEBUG output is always helpful.
Set the varibale GLOBALPLATFORM_DEBUG=1 in the environment. You can set
the logfile with GLOBALPLATFORM_LOGFILE=
Original comment by: kaoh
OK, I have received now the core with some delay.
Original comment by: kaoh
Can you run a "gdb gpshell core" on the core file. The files you sent me cannot be used as core file on my side.
Original comment by: kaoh
sigh Then I've likely destroied all five of the cards I bought. I didn't know that this type of thing could irreversably damage the card.
In fact, I don't even know whether the keys I'm using are actually the right keys for the card. I just saw that same key used for a bunch of other cards. I have no idea if the retailer that supplied me with these cards uses the same key or what (Although the same retailer has different types of java cards that reportedly use the same key)
I've blown way past that limit, and I still get segfaults. So at least even though I probably wrecked my cards (sigh), I can still generate segfaults. So I should be able to help you?
Original comment by: *anonymous
Oh.. unless you're saying I have 3 more tries on that particular card and you can tell from the output, and a card normally has many more than 3 tries?
Original comment by: *anonymous
I put in a card I used less than this one, and put the original card I've been using in a different drawer.. I won't mess with it unless we figure this problem out. Attempt made with debugging variables. Log:
Original comment by: *anonymous
No, you usually have 3 to 10 tries. The keys are all 404142 ... 4F by default.
Original comment by: nobody
14/06 22:14:21 -mutual_authentication in GlobalPlatform.c at line 5986 : end RV(0x80302000)
means:
static const DWORD OPGP_ERROR_CARD_CRYPTOGRAM_VERIFICATION = ((DWORD)0x80302000L); //!< The verification of the card cryptogram failed.
So maybe the key is not correct you are using.
The problems seems to arrise now while stringifying the error code.
in gpsell.c
_tprintf (_T("mutual_authentication() returns 0x%08X (%s)\n"), rv, stringify_error(rv));
or in globalplatform.c:
if (errorCode == OPGP_ERROR_CARD_CRYPTOGRAM_VERIFICATION)
return _T("The verification of the card cryptogram failed.");
I have no idea why one of both should cause a segmentation fault.
Original comment by: nobody
Okay. That answers my question about what's wrong, then. If the key is wrong, then I guess they changed it, since it's a retail card.
It makes sense, right? If someone knows the issuer domain key, then they can make the card do anything, including give up private keys, so a retail card provider would probably want to change the key before shipping it out.
Or am I mistaken about that?
Original comment by: *anonymous
I'll leave it to you to find out what's wrong with the stringification... hopefully the core dump can help you with that.
Original comment by: *anonymous
Yes, maybe the key is only known to the person which issued the card. The key usually must be kept secret. Well, I had problems wirh the core dump. Can you send me a gdb gpshell core output? stacktrace prints the stacktrace
Original comment by: nobody
One strange thing as well...
I've tried this same sequence probably 50 times .. screwing around with various things... yet it appears as though I had 3 tries left? If the number of tries I had was 53 to begin with, that would make sense.
Is there any possibility that mutual authentication is actually succeeding, but gpshell is failing to notice properly? Is 0x80302000 something that was generated by the card, or something that was generated from the globalplatform library? How would I make this determination?
Original comment by: nobody
In is very uncommon to have 53 tries. You cannot say how much tries are left. 0x80302000 is generated by the program. But is is only the first step in the key negotiation, the seond cannot succedd because the program cannot calculate the cryptogram correctly.
Original comment by: nobody
In is very uncommon to have 53 tries. You cannot say how much tries are left. 0x80302000 is generated by the program. But is is only the first step in the key negotiation, the seond cannot succedd because the program cannot calculate the cryptogram correctly.
Original comment by: nobody
the 0x80302000 is not known to PCSC/pcsclite.h all the defines tehre are 0x801xxxxx, can you explain whats going on?
Original comment by: nobody
Hi Daniel,
There is a new version under branches/globalplatform-6.0.0. You must compile globalplatform, gppcscconnectionplugin and gpshell. I can also give you binaries or Debian/Ubuntu packages.
Please give it a try. Does it fix it?
Karsten
Original comment by: kaoh
This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).
Original comment by: sf-robot
Hi, I recently bought some 'Aladdin eToken 64k SmartCard' cards and they turned out to not be the CardOS M4.2 I expected. I believe that they're java cards, so I tried using your gpshell-1.4.2 with globalplatform-5.0.0 to install 'MUSCLE' on them. I can't seem to get past the open_sc part. I tried to attach a core dump to this bug, but it wouldn't let me, and it made me type all this over again. Basically it fails with a segfault trying to output the error. [ _tprintf (_T("select_application() returns 0x%08X (%s)\n"), rv, stringify_error(rv)); <-- GPShell.c line 657 ]
Here's the output I get: mode_211 enable_trace establish_context card_connect select -AID A0000001510000 Command --> 00A4040007A0000001510000 Wrapped command --> 00A4040007A0000001510000 Response <-- 6F0F8407A0000001510000A5049F6501FF9000 open_sc -security 1 -keyind 0 -keyver 0 -mac_key 404142434445464748494a4b4c4d4e4f -enc_key 404142434445464748494a4b4c4d4e4f // Open secure channel Command --> 80CA006600 Wrapped command --> 80CA006600 Response <-- 663F733D06072A864886FC6B01600C060A2A864886FC6B02020101630906072A864886FC6B03640B06092A864886FC6B040105660C060A2B060104012A026E01029000 Command --> 80500000085B8C862E5609D12000 Wrapped command --> 80500000085B8C862E5609D12000 Response <-- 0000075200251654397301019AFE8E7260FD24BDAA71FB1357E168979000 Segmentation fault (core dumped)
With no error message I find it difficult to continue trying to solve the problem. Also, does anyone reading this have any advice to help me get MUSCLE onto these cards? Am I doing something wrong?
Reported by: nobody