I am trying to understand the concept of java card , I have some doubts , I want to share with , perhaps you would any best suggestion for me.
//Jcop- I read somewhere that Java Card OpenPlatform (JCOP) is a smart card operating system for the Java Card platform developed by IBM Zürich Research Laboratory.
question 1- if this above sentence is right it means jcop is an operating system developed by IBM, handle all operation inside the card.right?
I have a card which indicate
ATR like- 3b 89 80 01 4a ....40 ( in character form it indicate- ;---jcop41v22m) ,
so can i say? this is a card which o.s is made by IBM. and we require only and only JCOP tool to send cap inside this card because OS inside is JCOP and jcop tool would be the only option to talk to jCOp card?
question 2- or is there any other method by which i can send the applet inside my card?
enable_trace
establish_context
card_connect
select -AID a0000000030000
open_sc -security 1 -keyind 0 -keyver 0 -mac_key 404142434445464748494a4b4c4d4e4f -enc_key 404142434445464748494a4b4c4d4e4f // Open secure channel
delete -AID D0D1D2D3D4D50101
delete -AID D0D1D2D3D4D501
delete -AID D0D1D2D3D4D50101
install -file helloworld.cap -nvDataLimit 500 -instParam 00 -priv 2
# getdata
# close_sc // Close secure channel
# putkey // Put key
// options:
// -keyind Key index
// -keyver Key version
// -key Key value in hex
card_disconnect
release_context`
question 3- above code i got from gpshell 1.4.4 , the code style indictate that this is also a method tp send cap file inside the java card, I want to know that for my card case { atr is -3b 89 80 01 4a ....40 ( in character form it indicate- ;---jcop41v22m)} , I can apply gpshell to send .cap file in my card.
question 4- is gpshell is used to send cap into a special java card which is not jcop enable or which does not contaion jcop operating system?
there are so many techniques , so many type of java card, it makes me confuse , I hope you seems this question genuine and would give me revert back
regards:-
The question is good. I see a lot of people that work with smart card for years and cannot still get the picture.
What you read is right JCOP is operating system for smart cards.
Although it is NOT true that you have to use JCOP tool to deploy applets. They might be helpful but it is not the only way. In fact what you need to know is what version of Global Platform is supported by your card. Global Platform is the standard that defines how Card Contend is managed. This includes installation, security concept and so on. For example if your card support GP 2.1.1 you should use this document as a reference:
http://www.win.tue.nl/pinpasjc/docs/Card%20Spec%20v2.1.1%20v0303.pdf
All the tools like gpshell, jcshell are wrapping global platform commands in more user friendly commands, and also implementing the security protocols for you. So you can use whatever tool that supports the GP version of your target card.
I hope this makes it a bit more clear.
Answer to the subject of the question is:
NO.
Have a look at https://github.com/martinpaljak/GlobalPlatform
NXP currently owns JCOP, you should go to them for questions.
Yes, the VM inside a Java Card implementation executes all byte code.
You can use any Global Platform compatible library, although there are some implementation mistakes that could make a difference.
Try it, it should work
Java Card is a standard, and implementations are tested by Oracle, so sending your Applet to another card should work *1
*1 unless you make assumptions that are not cleared up in Java Card, use too much stack or heap memory for that card, use crypto algorithms that are not present, Java Card API's that have not been implemented by the other card, or of course, proprietary JCOP functionality.
The answer to question 1 is "no". You shouldn't rely on the historical bytes "jcop41v22" in the ATR to recognize the type of card. Any Java Card applet can change these bytes.
Q1&Q2: No.It's right that Java Card OpenPlatform (JCOP) is a smart card operating system for the Java Card platform.But it's not the only tool to deploy applet. For example,i'm using PyAPDUTool to send cap file inside the java card.
Q3: Yes,you can use gpshell to send .cap file in your card.
Q4: NO,you can also send your applet to other javacards.
NO.
You can take a look at this website "www.javacos.com" . On this the tool of jcide also can get what you want And it is free of charge.Although some function is not very perfect.
Related
I want to initiate pairing on Bluez with a Bluetooth Low Energy device.
While there are some posts on how to trigger the SMP procedures using GATT, there is not much available if you do not want to use GATT.
My use case is that I want to use an encrypted link for bluetooth-6lowpan which exchanges data over L2CAP credit based mode and not ATT/GATT.
Further, I would like to use the OOB mode for SMP pairing.
Pointers on how I could trigger SMP pairing either using command line or writing a C program is appreciated.
Thank you!
I don't think it's possible to perform BLE pairing without the use of GATT commands (from the command line only). The reason for this is that security in LE is GATT-action-based. In other words, the characteristic/service permissions dictate whether you need to pair with the device or not (i.e. to read the heart rate characteristic, the device might dictate that you need to be paired first). For this, the operation would be something like:
gatttool --sec-level=high --device=00:11:22:33:44:55:66 --char-read --uuid=0x2A37
This command will establish pairing first before reading the characteristic.
As for how to perform this using a C program, You can download the BlueZ source code and have a look at what passing this "sec-level" option does. I've quickly browsed through the code and found this in utils.c:-
chan = bt_io_connect(connect_cb, NULL, NULL, &tmp_err,
BT_IO_OPT_SOURCE_BDADDR, &sba,
BT_IO_OPT_SOURCE_TYPE, BDADDR_LE_PUBLIC,
BT_IO_OPT_DEST_BDADDR, &dba,
BT_IO_OPT_DEST_TYPE, dest_type,
BT_IO_OPT_CID, ATT_CID,
BT_IO_OPT_SEC_LEVEL, sec,
BT_IO_OPT_INVALID);
where sec is set with sec = BT_IO_SEC_HIGH;
I hope this helps.
I have the CC2540 Keyfob Development Kit and I have established connections between the bluetooth dongle and the Keyfob and have been able to do simple read writes. Then I connected the CC Debugger and download the SmartRF Flash Programmer and the IAR Workbench. All I want to do is change a few values in the firmware so that it broadcasts indefinitely and so that I can change the name it advertises with. I have read the Getting started docs and the sample applications docs but the problem is I don't know how to edit/compile these files so I can upload it to the device with the SmartRF flash programmer. Is there any documents or tutorials or are there steps to do this? Thank you! Let me know if I can answer any other questions
All you have to do is:
Download the BLE stack from Texas Instruments website:
http://www.ti.com/tool/ble-stack
Then in the stack, open Projects\ble\KeyFob\CC2540DB\KeyFobDemo.eww file.
Programming CC2540 kit requires an IDE named IAR Embedded Workbench. You can download it and get access with 30-days trial:
http://www.iar.com/Products/IAR-Embedded-Workbench/8051/
Then open the project and find the keyfobdemo.c file in the APP folder. From line 200-213 there is a char array named deviceName[], which actually defines the advertising name as "Keyfobdemo". You just have to change that with correct hex values, and the length of the array as well.
Then in line 236, you have to change attDeviceName[] array as well, since this parameter defines the name of your device, when it is in connected state.
The primary video card usually can be set in the BIOS (option Primary VGA card), and it will be the first card used by the system.
My question is how can I programmatically identify (using a shell script and utilities is preferable) which of my two video cards is the primary card?
Edit: I was hoping that I wouldn't have to elaborate why I need this, because it is a bit complex, but I will explain the problem below.
I have a configuration wizard which allows the dynamic configuration of a multiseat system in a LiveCD, with two independent displays, keyboards and mice, my wizard works in this way:
Start one Xorg server per video card (after generating xorg.conf with the correct PCI bus ID).
Start a ui in each of Xorgs with messages for configuration (press key and press mouse). One seat can be configured each time.
After the first seat is configured, the wizard closes the first Xorg and start the definitive Xorg in this seat with the desktop environment (already with the correct keyboard and mouse set).
The second seat now is able to be configured (press key and mouse), after this pass 3 is repeated for seat two.
The problem is: If I start the first Xorg in the primary video card, everything works, but if I start the first Xorg in the secondary card this is what happens:
The passes 1, 2, and 3 works, but at the end of pass 3, when the Xorg of the first seat is closed, the Xorg of the second seat blinks and doesn't come back, just show a blank screen with a _ cursor at top, the desktop of the first seat loads, but I don't see the wizard screen in the second seat, the first Xorg just comes back if I execute a kill -HUP , and I need to start the ui from it again.
So, it is why I need to identify the primary video card before I can start Xorg (sorry I didn't mention this before). I tested this system in different computers, with different video cards and the behavior is the same. I also tested with the lasted packages of the kernel and Xorg in Ubuntu 12.04 (packages of the raring release).
Assuming X11 is running, you could suppose that primary card is the one used by Xorg... then you might try
ls -l /proc/$(pidof X)/fd |grep /dev/dri
on my system Debian/Sid/x86-64 with Linux 3.12 kernel (which has an Nvidia card on a Intel3770K which also has its VGA) I'm getting /dev/dri/card0 etc...
But you should explain really why you are asking and what problem do you want to solve.... Why does that matter to you?
I am not at all sure that Linux has a notion of primary graphic card like the BIOS knows it.
And probably hwinfo is telling you everything about your graphical cards.
There are several command line tools in Linux that give you human readable information from the BIOS. Maybe you can find your Video boards in there and see which one is made primary. From what I see in my output, it does not look like something says "this is the primary video", but I do see quite a lot of information. You could output that information to a file when video card A is primary, again when B is primary, then compare those two files and see whether there is a difference.
The command I used, which gives me a lot of information, is dmidecode:
sudo dmidecode | less
If you look at the manual page:
man dmidecode
You will notice that the programmers offer a few other similar tools such as biosdecode and vpddecode.
From those you learn that the BIOS information is available from the /dev/mem device. Although you need to be root to read it, if you know the address (I don't) then you could go in there and peek and poke as required to find out where that one information of which video card is defined as the primary video card.
Running dmidecode, there are some details about my motherboard:
Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: Supermicro
Product Name: X9SCI/X9SCA
Version: 1.01
Serial Number: ZM25U44192
Asset Tag: To be filled by O.E.M.
Features:
Board is a hosting board
Board is replaceable
Location In Chassis: To be filled by O.E.M.
Chassis Handle: 0x0003
Type: Motherboard
Contained Object Handles: 0
Here I have one video entry:
Handle 0x000E, DMI type 10, 6 bytes
On Board Device Information
Type: Video
Status: Enabled
Description: To Be Filled By O.E.M.
Then the other entry looks like this:
Handle 0x0036, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard IGD
Type: Video
Status: Enabled
Type Instance: 1
Bus Address: 0000:00:02.0
It could also be something you need to read from the Flash memory your BIOS uses. This is done with flashrom (that you may need to install):
sudo flashrom --programmer internal --read my-flash.bin
In my case the ROM on my computer is 2Gb of data. So quite large. However, you can be sure that the information you are looking for exists within that data block since that is the only mean for the BIOS to save data that will stay around when the computer gets turned off.
I have found a way how to check the primary GPU when they are from different vendors or at least have different names.
In KDE go to Info Center, then open Graphics -> OpenGL. In Direct Rendering (GLX) and Direct Rendering (EGL) you can see a Driver block. You can see the Vendor and Device there. It will name the GPU which is primary.
At this screenshot you can see that AMD gpu is primary:
Also, you can get that Vendor value programmatically by running
glxinfo | grep "OpenGL vendor string" | cut -f2 -d":" | xargs.
I guess this method will stop working when kde will switch to vulkan for rendering (in kde 6). But for now I do not know another method of determining primary gpu.
Does anyone know of a good way to get a bi-directional dump of MIDI SysEx data on Linux? (between a Yamaha PSR-E413 MIDI keyboard and a copy of the Yamaha MusicSoft Downloader running in Wine)
I'd like to reverse-engineer the protocol used to copy MIDI files to and from my keyboard's internal memory and, to do that, I need to do some recording of valid exchanges between the two.
The utility does work in Wine (with a little nudging) but I don't want to have to rely on a cheap, un-scriptable app in Wine when I could be using a FUSE filesystem.
Here's the current state of things:
My keyboard connects to my PC via a built-in USB-MIDI bridge. USB dumpers/snoopers are a possibility, but I'd prefer to avoid them if possible. I don't want to have to decode yet another layer of protocol encoding before I even get started.
I run only Linux. However, if there really is no other option than a Windows-based dumper/snooper, I can try getting the USB 1.1 pass-through working on my WinXP VirtualBox VM.
I run bare ALSA for my audio system with dmix for waveform audio mixing.
If a sound server is necessary, I'm willing to experiment with JACK.
No PulseAudio please. It took long enough to excise it from my system.
If the process involves ALSA MIDI routing:
a virtual pass-through device I can select from inside the Downloader is preferred because it often only appears in an ALSA patch bay GUI like patchage an instant before it starts communicating with the keyboard.
Neither KMIDIMon nor GMIDIMonitor support snooping bi-directionally as far as I can tell.
virmidi isn't relevant and I haven't managed to get snd-seq-dummy working.
I I suppose I could patch ALSA to get dumps if I really must, but it's really an option of last resort.
The vast majority of my programming experience is in Python, PHP, Javascript, and shell script.
I have almost no experience programming in C.
I've never even seen a glimpse of kernel-mode code.
I'd prefer to keep my system stable and my uptime high.
This question has been unanswered for some time and while I do not have an exact answer to your problem I maybe have something that can push you in the right direction (or maybe others with similar problems).
I had a similar albeit less complex problem when I wanted to sniff the data used to set and read presets on an Akai LPK25 MIDI keyboard. Similar to your setup the software to setup the keyboard can run in Wine but I also had no luck in finding a sniffer setup for Linux.
For the lack of an existing solution I rolled my own using ALSA MIDI routing over virmidi ports. I understand why you see them as useless because without additional software they cannot help at sniffing MIDI traffic.
My solution was programming a MIDI relay/bridge in Java where I read input from a virmidi port, display the data and send it further to the keyboard. The answer from the keyboard (if any) is also read, displayed and finally transmitted back to the virmidi port. The application in Wine can be setup to use the virmidi port for communication and in theory this process is completely transparent (except for potential latency issues). The application is written in a generic way and not hardcoded to my problem.
I was only dealing with SysEx messages of about 20 bytes length so I am not sure how well the software works for sniffing the transfer of large amounts of data. But maybe you can modify it / write your own program following the example.
Sources available here: https://github.com/hiben/MIDISpy
(Java 1.6, ant build file included, source is under BSD license)
I like using aseqdump for that.
http://www.linuxcommand.org/man_pages/aseqdump1.html
You could use virtual midi devices for this purpose. So you have to load snd_seq_dummy so that it creates at least two ports:
$ sudo modprobe -r snd_seq_dummy
$ sudo modprobe snd_seq_dummy ports=1 duplex=1
Then you should have a device named Midi through:
$ aconnect -i -o -l
client 0: 'System' [type=kernel]
0 'Timer '
1 'Announce '
client 14: 'Midi Through' [type=kernel]
0 'Midi Through Port-0:A'
1 'Midi Through Port-0:B'
client 131: 'VMPK Input' [type=user,pid=50369]
0 'in '
client 132: 'VMPK Output' [type=user,pid=50369]
0 'out '
I will take the port and device numbers form this example. You have to inspect them yourself according to your setup.
Now you plug your favourate MIDI Device to the Midi Through ports:
$ aconnect 132:0 14:0
$ aconnect 14:0 131:0
At this time you have a connection where you can spy on both devices at the same time. You could use aseqdump to spy the MIDI conversation. There are different possibilities. I suggest to spy the connection between the loopback devices and the real device. This allows you for rawmidi connections to the loopback devices.
$ aseqdump -p 14:0,132:0 | tee dump.log
Now everything is set up for use. You just have to be careful about port names in your MIDI application. It should read MIDI data from Midi Through Port-0:B and write data to Midi Through Port-0:B.
Some additional hint: You could use the graphical frontend patchage for connecting and inspecting the MIDI connections via drag and drop. If you do this you will see that every Midi Through port occurs twice once as input and once as output. Both have to be connected in order to make this setup work.
If you want to use GMidiMonitor or some other application you spy on both streams intermixed (without showing the direction) using aconnect suppose 129:0 is the Midi Monitor port :
$ aconnect 14:0 129:0
$ aconnect 132:0 129:0
If you want to have exact direction information you could add another GMidiMonitor instance that you connect only to one of the ports. The missing messages come from the other port.
What about using gmidimonitor? See http://home.gna.org/gmidimonitor/
I have a telephony modem which gives voice to my interfaced application via a serial USB ttyUSB0 in 16bit PCM 8000hz. I am able to capture this data and play with audacity. I want this port to be detected as a sound device in linux (I am on ubuntu). Is it possible? Are there any other options?
I'm guessing you are using a huawei 3G modem or something similar which gives ttyUSB1 for audio. Make sure you have the serial driver binded to it. Then simply pass the port itself as a "file" for input for any program of your choice.You need root access for that.You figured out the audio settings so it must be enough.I have voice calling working in UBUNTU 11.10 with Huawei. So let me know if i can help any further.
Ok, I see it's very old question but answers helped me to get a right direction so I decided to help others.
The one way to achieve (in addition to below) what are you are
looking for is to write dynamic kernel module.
Have it register as a sound device, and check that it has a GSM
module present (which module is it exactly can be recognized in
dmesg, lsmod, or output).
Then establish communication between user space representation as a
sound card and serial usb module.
The other way is to get module that you recognized by dmesg, lsmod and extend its functionality as a sound card.
All are tricky tasks because:
in the first case you have to resolve intermodule communication at the kernel level...... which is, lets say, a little hard even if programmer has a right background in subject.
the second case is hard in that you have to deal with:
USB stack (which is little unpleasant for human beings) and
sound subsystem (which is a little burdensome because of historical issues).
Without being an experienced kernel programmer there are small chances to succeed.