I'm sorting out how to achieve the following, I want to use smart or memory cards in a project. The cards should be read by standardized card readers (for example ACR38). When they are read by the computer ( command line or by a software (processing or p5js or similar), there should be a popup a window which shows the contents of the card being a picture and a text. Bit similar when I use my regular ID to be read by my E-idsoftware.
For the moment the card I have is this one SLE4428 (at the bottom instructions from the vendor)
These have no data on it yet and are bought blank
=> datasheet
The software I found but don't know if it's suited for my project and how to specifically use it is the following.
Opensource tools that I found when searching for SC cards software (no id how to use them.)
https://linux.die.net/man/1/opensc-tool
https://linux.die.net/man/1/opensc-explorer
I looked at my smartcard reader and found that http://www.acr38u.com/
is a platform but has to be payed for and I'm unable to found sofware for this on linux or apple.
Again here I found a datasheet with hex code to connect to the card, but still not how to physically connect to the cards.
This site shows many points of a working shell but I can't find the installer for it. opendsc
Then lastly this is the most promising and I already contacted the maker of it. But installation gets stuck in the make process (which I've already searched for and is not solution yet, being at it for a week now so therefore this post, maybe the community can help with an alternative look)
This is the explanation from the vendor side (Aliexpress) which is kind of specific. Though I don't know where to input these hex codes to write or read from the card. (there is a software but it's windows (If there is somebody that can say, that the way to solve the core question of my project then I'll try to get a windows pc to work on it via that way))
ISO7816 SLE 4442 Chip PVC Contact Smart Card (0.8* 85.5 * 54mm)
If you need write the 4442 cards,you should buy the contact smart reader writer!! 4442 cards not support 13.56mhz rfid writer!!!
NOTE:There is NO magnetic strip behind the card.
Graphics Quality Cards For All Photo ID Card Printers Including
DataCard, Zebra, Fargo, Evolis, Magicard, NBS & etc.
(These Cards Will Not Work In Inkjet Printers)
If you need 100pcs 4442 cards,pls check the links below:
[https://www.aliexpress.com/store/product/100-pcs-lot-ISO7816-RFID-Contact-SLE-4442-Chip-PVC-Smart-Card/516120_32425491077.html?spm=2114.12010608.0.0.R0bzFx][1]
Features:
Standard:ISO7816
Product Chip:SLE4442
Color:White
Dimension: L 85.5 x W 54 x H 0.80±0.04mm
256 × 8-bit EEPROM organization
32 × 1-bit organization of protection memory
erase cycles more than 100,000 times
Data retention for minimum of ten years
Default passwords: FFFFFF
3 bytes for error counter and card secret code area
1,Write protected area (first 32 bytes) of each byte can be individually write protected, After write,the data can't be changed.
2, Before checking the password, all the data can be read, if necessary,you could encryption data.
3, After confirm password is correct,the data could be write or modify.
4, The 3 bytes of user passwords, after confirm is correct,it could be change.
5, The password error counter, the initial value of 3, check the error code 1, then subtract 1, if the counter value is 0, the card is automatically locked, the data just read out, no longer change can no longer be password verification; if zero, the one time password verification is correct, restore to the initial value.
6, The byte address 0-5,6-7 factory prior written by the manufacturers can not be changed.
The specifics for this question lies in either
A: How can I achieve a working environment on linux or mac (first) to read and write data on an sc card (the one I have or !B: a working alternative)
C: Create a viewer program or webapp, etc.. to view or route the data to when the SC card is being read. (This would be a valid question, If i where to chose a Windows based existing program, I think)
Because this is not code specific, but I still want people that have the same questions to be able to see this page to show them pletora of scripts and ways to approach this or similar SC project.
This guy knows a lot about OpenSC!
Related
I made an app that discovers Bluetooth devices around me, and I'm looking into the datas I get about them. Now I'm trying to figure out the datas from BluetoothDevice.getBluetoothClass (CoD, Class of Device).
So far I've found these class codes around me:
43c
50c
704
1f00
c043c
c243c
8043c
60680
200408
240414
5a020c
About half of these I found some information for (http://domoticx.com/bluetooth-class-of-device-lijst-cod/). The rest of the codes I haven't been able to find anywhere (50c, c043c, c243c, 60680).
Does anyone know any overview with all of these codes (or at least the ones I haven't figured out)?
You can decode the Bluetooth Class of Device (CoD) yourself by first converting the above hex number to binary (for example using this link) and then checking the document below to try and find what the combination of the bits mean:-
https://www.ampedrftech.com/datasheets/cod_definition.pdf
As an example, 0x50c is 010100001100 in binary. Using the table in the document above, bits 8 to 12 indicate that the device is a peripheral:
And then bits 2 to 5 indicate that the device is a remote control
I'm trying to set up my LabView VI + my USB 6001 I/O box to be able to read multiple independent voltages at once, while also outputting a single constant voltage.
I've successfully gotten my USB box to output the voltage I want while reading back a single voltage, but so far I've been unable to read back more than one voltage (and if I do, the two voltages seem to be co-dependent on one another in some way).
Here's a screenshot of my VI:
Everything to the right of the screenshot window should be unimportant to the question.
If anyone is curious, this is to drive multiple LVDT's and read back their respective voltages.
Thank you all for your help!
Look at your DAQ's manual, especially the pages I noted below.
http://www.ni.com/pdf/manuals/374259a.pdf
Page 11
All the AI channels get multiplexed, and the low-side reference can be switched (RSE vs. differential). So the two channels you're sampling require both of those to switch. It might be a settling issue where the ADC is taking a sample before the input value is stable.
To verify this, try using using the same low side (differential or RSE) on both channels. Also try slowing down your sample rate (but your 1 kHz should already be slow enough...).
Page 14
Check this to make sure you have everything connected and grounded correctly.
Page 18
Check this for more details about switching between 2 sources quickly.
Perhaps you could try it using the Daqmx express VIs:
http://www.ni.com/tutorial/2744/en/
Does anyone know how to reset an Advanced Card Systems NFC reader type ACR1255U-J1? I've sent an escape command to it and it got stuck. When I switch the button at the top I get a purple light for LED1 and orange light for LED2 followed by red light for LED1 and no light for LED2. Any help will be appriciated.
I can see the device through Mac Terminal when it is connected through USB but it is no longer visible when bluetooth is on.
Once the ACS1255U-J1 shows the behavior you described it's basically bricked. It happens because of a stack overflow problem (no pun intended) in the readers' firmware and ACS is currently working to correct it. I've seen it happen repeatedly with very long Escape Commands like the Rewrite Master Key Command Request (36 bytes long) as well as some shorter ones. Depending on the severity of the overflow, you may be able to resurrect the reader by reflashing it with fresh firmware. You can download all the stuff you need from our site here:
http://flomio.com/ACR1255U-J1-FlashTool/
You'll need a Win7 machine to work the tool and even then it'll take a few tries to get the reader in DFU mode. If you run into issues, post support questions on our forums and we'll be happy to help.
That said your device corruption may be beyond repair. This can happen if you've wiped out the boot sector of the flash. You'll know this if the reader fails to enter DFU mode. I've been able to resurrect a few readers but found them lacking some key setting like the serial number field being gone (all zeros). But more just don't enter DFU. We're authorized distributors of ACS products so if you want to RMA your device through us let me know and we can work something out.
UPDATE: Flomio now has the ability to repair bricked ACR1255U-J1 units. You can ping us on our forums for details.
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.
I have created a small wireless network using a few PIC microcontrollers and nRF24L01 wireless RF modules. One of the PICs is PIC18F46K22 and it is used as the main controller which sends commands to all other PICs. All other (slave) microcontrollers are PIC16F1454, there are 5 of them so far. These slave controllers are attached to various devices (mostly lights). The main microcontroller is used to transmit commands to those devices, such as turn lights on or off. These devices also report the status of the attached devices back to the main controller witch then displays it on an LCD screen. This whole setup is working perfectly fine.
The problem is that anybody who has these cheap nRF24L01 modules could simply listen to the commands which are being sent by the main controller and then repeat them to control the devices.
Encrypting the commands wouldn’t be helpful as these are simple instructions and if encrypted they will always look the same, and one does not need to decrypt it to be able to retransmit the message.
So how would I implement a level of security in this system?
What you're trying to do is to prevent replay attacks. The general solution to this involves two things:
Include a timestamp and/or a running message number in all your messages. Reject messages that are too old or that arrive out of order.
Include a cryptographic message authentication code in each message. Reject any messages that don't have the correct MAC.
The MAC should be at least 64 bits long to prevent brute force forgery attempts. Yes, I know, that's a lot of bits for small messages, but try to resist the temptation to skimp on it. 48 bits might be tolerable, but 32 bits is definitely getting into risky territory, at least unless you implement some kind of rate limiting on incoming messages.
If you're also encrypting your messages, you may be able to save a few bytes by using an authenticated encryption mode such as SIV that combines the MAC with the initialization vector for the encryption. SIV is a pretty nice choice for encrypting small messages anyway, since it's designed to be quite "foolproof". If you don't need encryption, CMAC is a good choice for a MAC algorithm, and is also the MAC used internally by SIV.
Most MACs, including CMAC, are based on block ciphers such as AES, so you'll need to find an implementation of such a cipher for your microcontroller. A quick Google search turned up this question on electronics.SE about AES implementations for microcontrollers, as well as this blog post titled "Fast AES Implementation on PIC18F4550". There are also small block ciphers specifically designed for microcontrollers, but such ciphers tend to be less thoroughly analyzed than AES, and may harbor security weaknesses; if you can use AES, I would. Note that many MAC algorithms (as well as SIV mode) only use the block cipher in one direction; the decryption half of the block cipher is never used, and so need not be implemented.
The timestamp or message number should be long enough to keep it from wrapping around. However, there's a trick that can be used to avoid transmitting the entire number with each message: basically, you only send the lowest one or two bytes of the number, but you also include the higher bytes of the number in the MAC calculation (as associated data, if using SIV). When you receive a message, you reconstruct the higher bytes based on the transmitted value and the current time / last accepted message number and then verify the MAC to check that your reconstruction is correct and the message isn't stale.
If you do this, it's a good idea to have the devices regularly send synchronization messages that contain the full timestamp / message number. This allows them to recover e.g. from prolonged periods of message loss causing the truncated counter to wrap around. For schemes based on sequential message numbering, a typical synchronization message would include both the highest message number sent by the device so far as well as the lowest number they'll accept in return.
To guard against unexpected power loss, the message numbers should be regularly written to permanent storage, such as flash memory. Since you probably don't want to do this after every message, a common solution is to only save the number every, say, 1000 messages, and to add a safety margin of 1000 to the saved value (for the outgoing messages). You should also design your data storage patterns to avoid directly overwriting old data, both to minimize wear on the memory and to avoid data corruption if power is lost during a write. The details of this, however, are a bit outside the scope of this answer.
Ps. Of course, the MAC calculation should also always include the identities of the sender and the intended recipient, so that an attacker can't trick the devices by e.g. echoing a message back to its sender.