Out of curiosity I was inspecting the official registrar of 16bit UUIDs:
https://btprodspecificationrefs.blob.core.windows.net/assigned-values/16-bit%20UUID%20Numbers%20Document.pdf
Is it me or is the number-space reserved for companies running out. What I mean to say is that even though 16bits are enough for 65536 numbers, in the document we see that company-ids start from 0xFCDC (64732) and up.
The greatest company-id seems to be 0xFEFF (=65279 held by 'GN Netcom'. So there seem to be only around 244 IDs left to be bought.
If those 244 IDs are exhausted what will the Bluetooth SIG do? Expand to 32bit or try to recycle 16bit IDs that have already been used by companies which have vanished?
You are mistaken. This list grows downwards and the 16-bit UUID for Members 0xFEFF GN Netcom is the first one that was registered. The latest entry is 0xFCDC Amazon.com Services, LLC, so I assume that there is still plenty of room for the next years. And last but not least, a fee of $3,000 USD is charged for registering a 16-bit UUID.
Related
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!
For BLE advertising type LOCAL_NAME_COMPLETE, is there a minimum length requirement?
I could not find any length specification in the spec (other than it needs to fit in the advertising packet of 31 bytes minus anything else already in the advertisement packet), but am running into an issue where it may seem that there is. I wanted to confirm here.
According to the BLUETOOTH SPECIFICATION Version 4.0 [Vol 3] section 12.1:
...The Device Name characteristic value shall be 0 to 248 octets in length. A
device shall have only one instance of the Device Name characteristic.
But since the AD packet is limited to 31 bytes then I guess that if it's too big then one should broadcast the shortened name instead of full name (different AD types)
So it seems like there is no limitations on a minimum size. Hope it helped.
I've read in many places that RSSI is highly environment specific (e.g., walls or weather) which can make it difficult to infer which beacon is the closest in a Euclidean sort of way. I also gather that RSSI is measured in arbitrary units from 0 (good connection strength) to -100 (bad connection strength). In spite of these challenges, I have questions about the following two thought experiments related to the reliability of the RSSI values for beacon <--> device communications.
Experiment 1. Given a particular beacon and two devices located at the exact same location, will those two devices register the same RSSI for that beacon?
Experiment 2. Given a particular device and two beacons located at the exact same location, will those two beacons register the same RSSI for that device?
To formalize this in a statistical sense, will p(signal | beacon1, device1) = p(signal | beacon2, device2) if beacon1-device1 are placed in the exact same environment of beacon2-device2?
Since different antennas and devices have different RF properties, I'm going to go ahead and say that unless your beacons/devices are identical to each other, then no, you should not expect the same RSSI reading, even if their locations are identical. This is because the device cannot know how much power is in an RF signal before it passes through its circuitry, and better and bigger antennas will transmit/receive better than crappier ones.
That said, RSSI values of 0 will be read as 0 with both devices, and also maximum RSSI values, assuming that the two devices use the same RSSI scale, which doesn't seem to have to be the case, as wikipedia says: "As an example, Cisco Systems cards have a RSSI_Max value of 100 and will report 101 different power levels, where the RSSI value is 0 to 100. Another popular Wi-Fi chipset is made by Atheros. An Atheros based card will return an RSSI value of 0 to 127 (0x7f) with 128 (0x80) indicating an invalid value."
Anyway, if your devices are identical, then I would expect the readings to be identical as well, or at least very close to each other.
Besides the differences in hardware and transmission power, timing is also important. If the interval between two measurements conducted by either the same device/beacon or different ones exceed channel coherence time, RSSI may vary drastically. Coherence time in indoor environment is at the level of 1s, and 10-100 times smaller outdoor.
I need to read serial number of MiFare card usin WinSCard. I am able to read 7B UID from the MiFare card.
The confusion is that i dont know if the UID and the serial number of
MiFare card are same?!!
I have googled the issue but only could get partial success. I found a question on stackoverflow also but it did not help.
I found a document of NXP online which says UID and serial number are different. (on page number 3, line number 5)
There is an application of OmniKey that reads the serial number of the card, and it also returns UID only.
NXP documentation says UID <> Serial Number and a other standard OmniKey application returns UID as Serial Number.
I have started pulling my hair off on the issue. I'd greatly appreciate if anyone could help.
Each smart card contains an integrated chip with a unique permanent identification (UID) number burned-in during the manufacturing process. This UID is often referred to as the Card Serial Number (CSN). The card serial number is not encrypted and any reader that is ISO compliant can read the card serial number.
Edit 1:
Mifare Card Serial Number is the unique identifier defined in ISO 14443-3A. There are 3 types of UID defined in the standard - single (4 bytes), double (7 bytes) and triple (10 bytes). Only in first versions of the Mifare card, the UID was 4 bytes but now have migrated to 7 bytes.
EDIT 2:
It might be helpful to you...
What is the difference between a 4 byte UID and a 4 byte ID?
A 4 byte UID is an identifier which has been assigned by the card
manufacturer using a controlled database. This database ensures that a
single identifier is not used twice. In contradiction, a 4 byte ID is an
identifier which may be assigned to more then one contactless chip over
the production time of a product so that more then one card with the same
identified may be deployed into one particular contactless system.
The differentiation in this case comes from the fact that a "Serial Number" implies that the numbers are a series, thus sequentially assigned.
MIFARE cards have Unique Identification Numbers (or in short UID), which are generated by an internal rule which is not necessarily sequential. This means that if you see a card with UID 01020304050607 it does not mean that there are at least that many cards produced so far.
If you ever see someone referring to the Card Serial Number, they are in fact referring to the UID.
The only last confusion can come from the fact that MIFARE cards can be configured to return Random IDs during activation. If that is the case, you would get different "UID" each time you activate the card. In that scenario you need to read the data contained in Block 0 (for which you will need to know the key to sector 0) to get the real UID of the card.
For DesFire cards:
UID is analogous to ethernet MAC address. It is assigned by the chip
manufacturer from a database. Everyone who creates applications for
the card has access to the UID.
The Card Serial Number is specific
to the application loaded on to the card. It can only be accessed by
that application via an encryption key. If the card had several applications loaded on to
it (unlikely but possible), then each could have a different CSN.
Trying to get access to a partially rooted Galaxy S2 external sd card.
The problem is that /dev/block/mmcblk1p1 does not exist on the phone. This is the device name that should allow me to put the "recovery" image onto the sdcard so that the unit will be a phone again.
Problem is, I don't know where to find the magic Major and Minor numbers for this device and I'm trying to figure out where in the kernel source I should be looking for them.
Could someone point me at the right kernel files to find this information?
Standard devices use predefined major numbers and minor numbers starting from 0 for the first instance and upward depending on how many instances there are going to be.
Look at the Linux Documentation file(devices.txt) to see the full list but the section of interest to you is:
179 block MMC block devices
0 = /dev/mmcblk0 First SD/MMC card
1 = /dev/mmcblk0p1 First partition on first MMC card
8 = /dev/mmcblk1 Second SD/MMC card
...
The start of next SD/MMC card can be configured with
CONFIG_MMC_BLOCK_MINORS, or overridden at boot/modprobe
time using the mmcblk.perdev_minors option. That would
bump the offset between each card to be the configured
value instead of the default 8.
So /dev/block/mmcblk1p1 would be major 179, minor 9.
According to hotplug.txt
Entries for block devices are found at the following locations:
/sys/block/*/dev
/sys/block/*/*/dev
So try looking in /sys/block/mmcblk1p1/dev.
EDIT:
Looking at it again I actually think that it will be in /sys/block/mmcblk1/mmcblk1p1/dev