STK can run some commands. In all resources (despite few resources) call the commands "Proactive".
What is proactive command and what another type of command is against it?
My bet is that the term "proactive command" derives from the term "proactive SIM" -- citing GSM 11.14 (now superseded by 3GPP 31.111 document which no longer contains this definition):
proactive SIM: A SIM which is capable of issuing commands to the ME within the T=0 protocol.
Specifications talk about "proactive commands" to differentiate them from normal SIM commands as defined in GSM 11.11 (like READ BINARY, VERIFY CHV, RUN GSM ALGORITHM...) issued by the ME (phone) to the SIM.
In short:
"proactive commands" are commands given by the SIM to the ME/phone (e.g. DISPLAY TEXT)
"non-proactive commands" are commands given by the ME/phone to the SIM (e.g. RUN GSM ALGORITHM)
The "proactive commands" in fact leverage the "non-proactive commands" like FETCH/TERMINAL RESPONSE/ENVELOPE as their communication channel (together with the status word in any other "non-proactive command" Response-APDU -- e.g. 91XX).
I hope this makes some sense!
EDIT> You might want to look here as well
Related
I am working on a DPDK project and experience issues that need you help.
The project needs to implement encryption/decryption through DPDK (multi-buffer library). To support all cipher and hash algorithms, I need create 4 type of virtual devices: crypto_null, crypto_aesni_mb, crypto_snow3g and crypto_zuc. I tried to create a crypto-scheduler to manage all 4 devices. When the devices attach to the scheduler, it failed. I can reproduce the exact same failure with the DPDK example program: l2fwd_crypto.
Here is the command I use to run l2fwd_crypto.
./l2fwd-crypto -l 0-1 -n 4 --vdev "crypto_aesni_mb0" --vdev "crypto_null" --vdev "crypto_zuc" --vdev "crypto_snow3g0" --vdev "crypto_scheduler,slave=crypto_null,slave=crypto_aesni_mb0,slave=crypto_snow3g0,slave=crypto_zuc" -- -p 0x3 --chain CIPHER_HASH --cipher_op ENCRYPT --cipher_algo aes-cbc --cipher_key 00:01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:0f --auth_op GENERATE --auth_algo aes-xcbc-mac --auth_key 10:11:12:13:14:15:16:17:18:19:1a:1b:1c:1d:1e:1f
The error message is:
rte_cryptodev_scheduler_slave_attach() line 214: capabilities update failed
I am using DPDK 20.05 on CentOS 7.4
My question is:
Is this the correct way to handle all different crypto algorithm? I mean create 4 virtual devices.
Why the crypto scheduler failed?
Any suggestion/comments are really appreciated.
[EDIT-1: Based on comment conversation]
DPDK POLL mode Crypto Scheduler is intended to be running with either HW or SW of the same type. This is covered in dpdk document. Hence if one needs to Crypto scheduler to work, it has to initialized with all same type (either HW/SW).
Hence re-running the test with either all NULL, ZUC, SNoW, AES_MB will work
note: with respect to internally logic working, my personal opinion is the current logic in crypto-scheduler logic is correct. Because, in actual logic one will lookup dest-ip or src+dest IP in either ACL, LPM, or Exact Match to identify the SA or Crypto keys. this can offloaded to SW or HW depending upon work load or flow (mice or elephant) flow.
I will be asking a very subjective question, but it is important as I am looking to recover from failure to effectively use BlueZ programatically.
Basically I envision an IoT edge device that runs on a miniature computer (Ex: Raspberry pi or Intel Compute Stick). The device would then run AlpineLinux OS and interact with Cloud.
Since it is IoT environment, it is needless to mention the importance of Bluetooth BLE over ISM band. Hence the central importance of being able to customize and work with BlueZ.
I am looking to do several things with BlueZ BLE including but not limited to
Advertising
Pairing
Characteristic
Broadcast
Secure transport of data etc...
Since I will be needing full control over data, for data-processing and interacting with cloud (Edge AI or Data-science on Cloud) I am looking at three ways of using BlueZ:
Make DBus API calls to BlueZ Methods.
Modify BlueZ codebase and make install a custom bin.
(So that callback handlers can be registered and wealth of other bluez
methods can be invoked)
Invoke BlueZ using command line utils like hcitool/bluetoothctl inside a program using system() calls.
No 1 is where I have failed. It is exorbitant amount of effort to construct and export DBus objects and then to invoke BlueZ methods. Plus there is no guarantee that you will be able to take care of all BLE issues.
No 2 looks very promising and I want to fully explore how feasible it is to modify the BlueZ code to my needs.
No 3 is the least desirable option, but I want to have it as a fallback option nevertheless.
Given my problem statement, what is the most viable strategy forward? I am asking this aloud so that I do not make more missteps and cost myself time and efforts.
Your best strategy is to start with the second way (which you already found promising) as this is a viable solution and many developers go about this method in order to create their BlueZ programs. Here is what I would do:-
Write all the functionality of the system in some sort of flowchart or state machine. This helps you visualise your whole system and what needs to be done to reach your end goal.
Try to perform all the above functionality manually using bluetoothctl and btmgmt. This includes advertising, pairing, etc. I recommend steering away from legacy commands such as hcitool and hciconfig as these have been deprecated and have a very different code structure.
When stumbling upon something that is not the default in bluetoothctl/btmgmt or you want to tweak the functionality, update the source to do so.
Finally, once you manually get the system to perform the functionality that you need (it doesn't have to be all, it can just be a subset of the functions), you can move to automating the whole process. This involves modifying the source for bluetoothctl/btmgmt commands so that instead of manual intervention, everything would be event-driven.
This is a bonus, but if you can create automated tests using python or some other scripting language, then this would ensure that your system is robust and that previous functionality doesn't break when adding new ones.
By the end of this process, you'll have a much better understanding of the internals of bluetoothctl/btmgmt and D-BUS APIs that you might be able to completely detach your code from the original bluetoothctl/btmgmt or create the program from scratch.
You probably already know this, but when modifying the tools, this is the starting point for the source code:-
bluetoothctl - client/main.c
btmgmt - tools/btmgmt.c
For more references on using bluetoothctl commands and btmgmt, please see the links below:-
BlueZ D-Bus C or C++ Sample
Bluetoothctl set passkey
https://stackoverflow.com/a/51876272/2215147
Bluez Programming
Linux command line howto accept pairing for bluetooth device without pin
https://stackoverflow.com/a/52982329/2215147
Bluetooth Low Energy in C - using Bluez to create a GATT server
I hope this helps.
On a test server there are two Samsung 960 Pro SSDs, exactly same maker, model and size. On both I've installed a fresh install of exactly the same OS, OmniOS r15026.
By pressing F8 at POST time, I can access the motherboard BOOT manager, and choose one of the two boot drives. Thus, I know which one the system booted from.
But how can one know programmatically, after boot, which is the boot disk?
It seems that is:
Not possible on Linux,
Not possible on FreeBsd
Possible on macOS.
Does Solaris/illumos offer some introspective hooks to determine which is the boot disk?
Is it possible to programmatically determine which is the boot disk on Solaris/illumos?
A command line tool would be fine too.
Edit 1: Thanks to #andrew-henle, I have come to know command eeprom.
As expected it is available on illumos, but on test server with OmniOS unfortunately it doesn't return much:
root#omnios:~# eeprom
keyboard-layout=US-English
ata-dma-enabled=1
atapi-cd-dma-enabled=1
ttyd-rts-dtr-off=false
ttyd-ignore-cd=true
ttyc-rts-dtr-off=false
ttyc-ignore-cd=true
ttyb-rts-dtr-off=false
ttyb-ignore-cd=true
ttya-rts-dtr-off=false
ttya-ignore-cd=true
ttyd-mode=9600,8,n,1,-
ttyc-mode=9600,8,n,1,-
ttyb-mode=9600,8,n,1,-
ttya-mode=9600,8,n,1,-
lba-access-ok=1
root#omnios:~# eeprom boot-device
boot-device: data not available.
Solution on OmniOS r15026
Thanks to #abarczyk I was able to determine the correct boot disk.
I had to use a slightly different syntax:
root#omnios:~# /usr/sbin/prtconf -v | ggrep -1 bootpath
value='unix'
name='bootpath' type=string items=1
value='/pci#38,0/pci1022,1453#1,1/pci144d,a801#0/blkdev#w0025385971B16535,0:b
With /usr/sbin/format, I was able to see entry corresponds to
16. c1t0025385971B16535d0 <Samsung-SSD 960 PRO 512GB-2B6QCXP7-476.94GB>
/pci#38,0/pci1022,1453#1,1/pci144d,a801#0/blkdev#w0025385971B16535,0
which is correct, as that is the disk I manually selected in BIOS.
Thank you very much to #abarczyk and #andrew-henle to consider this and offer instructive help.
The best way to find the device from which the systems is booted is to check prtconf -vp output:
# /usr/sbin/prtconf -vp | grep bootpath
bootpath: '/pci#0,600000/pci#0/scsi#1/disk#0,0:a'
On my Solaris 11.4 Beta system, there is a very useful command called devprop which helps answer your question:
$ devprop -s bootpath
/pci#0,0/pci1849,8c02#1f,2/disk#1,0:b
then you just have to look through the output of format to see what that translates to. On my system, that is
9. c2t1d0 <ATA-ST1000DM003-1CH1-CC47-931.51GB>
/pci#0,0/pci1849,8c02#1f,2/disk#1,0
Use the eeprom command.
Per the eeprom man page:
Description
eeprom displays or changes the values of parameters in the EEPROM.
It processes parameters in the order given. When processing a
parameter accompanied by a value, eeprom makes the indicated
alteration to the EEPROM; otherwise, it displays the parameter's
value. When given no parameter specifiers, eeprom displays the values
of all EEPROM parameters. A '−' (hyphen) flag specifies that
parameters and values are to be read from the standard input (one
parameter or parameter=value per line).
Only the super-user may alter the EEPROM contents.
eeprom verifies the EEPROM checksums and complains if they are
incorrect.
platform-name is the name of the platform implementation and can be
found using the –i option of uname(1).
SPARC
SPARC based systems implement firmware password protection with
eeprom, using the security-mode, security-password and
security-#badlogins properties.
x86
EEPROM storage is simulated using a file residing in the
platform-specific boot area. The /boot/solaris/bootenv.rc file
simulates EEPROM storage.
Because x86 based systems typically implement password protection in
the system BIOS, there is no support for password protection in the
eeprom program. While it is possible to set the security-mode,
security-password and security-#badlogins properties on x86 based
systems, these properties have no special meaning or behavior on x86
based systems.
Just any old GSM compatible SIM card (bonus for 3G USIM).
I presume I need some hardware? Can anyone recommend something cheap for hobbyist, and something more professional?
I presume that there will be full docs of an API with the h/w, so maybe this should be tagged "no-programming-related"? Sorry, if so.
Any good URLs or books (I am conversant with the 3GPP standards).
I'm not (black hat) hacking, don't worry, just not pleased with the likes of SIM Card Secretary, Data Doctor Recovery, etc, so would like to code my own, but might turn it commercial, or offer SIM card programming services (data recover from damaged card, etc) as a sideline.
Update: while I am primarily interested just reading my SMS for backup, it might be a bonus if someone knows of a cheap SIM card writer (so that I can back up all or part of the SIM and restore it later)
You can do that with any PC/SC smart card reader (and writer, as others pointed out) and a program that can read and parse the data for you.
Talking to a card is done via APDU commands (defined in ISO-7816)
The command set used by SIM (2G) and USIM (3G) cards is different, so you have to keep that in mind
The structure and format of the file system of a SIM card is defined in GSM 11.11 (for 2G) and ETSI TS 131.102 (for 3G) - all this documentation is public and available free of charge
The SMS are kept in a file called EF SMS, its name is 0x6F3C, its structure is defined in section 10.5.3 of GSM 11.11
Direct answers to your questions:
Here's where to buy a SIM reader, click on 'photos' to see pics of the device and screenshots of the software
SIM Manager is the program that does everything you want (including reading SMS, restoring SMS, it can even attempt to recover deleted SMS - if they're still physically on the card)
A SIM card SDK is available too. It is a DLL you can load and apply in your program. This thing does all the hard work for you, all you need is to create a GUI on top of it
I am one of the people from the team that created SIM Manager and the aforementioned SDK.
You'll certainly need a smartcard reader and from what I've been able to find out, pretty much any one will do because they all have to support the standard functionality. They also happen to be pretty cheap. Mine is an OmniKey (not sure what model because I don't have it here right now).
Presuming that you're developing under Windows, the Windows API has functions that make it possible to access smartcards. Here is an article on CodeProject that discussees this in greater detail as part of a set of several C# classes that give you access to a bunch of this stuff without having to tangle with the nuts and bolts. I think that the guy's example app is specifically for SIM cards, so that'll probably help.
There's lots of products and hardware to read and write SIM cards, have a look at http://forum.gsmhosting.com/vbb/f500/ in this forum you will find plenty of info concerning sim cards, mobile phones.. one of the bigest resource since 1999!
for hardware programmers, you can build your own like JDM or ICprog.. check kiscan.net for some info..
You can use simLAB tool for reading and editing almost any SIM file.
It works with every PC/SC smartcard reader. The tool also allows you to backup SIM file system.
Have a look at https://github.com/kamwar/simLAB
pySim
In the below example, we are changing the card’s IMSI to
901700000003080 (option -i) and we are specifying a new set of -n NAME
(Operator name), -t TYPE (Card type), -c CC (Country code), -x MCC
(Mobile Country Code), -y MNC (Mobile Network Code) and -s ID
(Integrated Circuit Card ID) values.
$ ./pySim-prog.py -p 0 -n OpenBSC -t sysmosim-gr1 -i 901700000003080 -c 001 -x 001 -y 02 -s 1791198229180000075
Is it enough just filling the new SIM card with new meta and will it working the same way as original? pyusb
Here is the full list of options:
$ ./pySim-prog.py -help
Usage: pySim-prog.py [options] Options:
-h, --help show this help message and exit
-d DEV, --device=DEV Serial Device for SIM access [default: /dev/ttyUSB0]
-b BAUD, --baud=BAUD Baudrate used for SIM access [default: 9600]
-p PCSC, --pcsc-device=PCSC
Which PC/SC reader number for SIM access
-t TYPE, --type=TYPE Card type (user -t list to view) [default: auto]
-a PIN_ADM, --pin-adm=PIN_ADM
ADM PIN used for provisioning (overwrites default)
-e, --erase Erase beforehand [default: False]
-S SOURCE, --source=SOURCE
Data Source[default: cmdline]
-n NAME, --name=NAME Operator name [default: Magic]
-c CC, --country=CC Country code [default: 1]
-x MCC, --mcc=MCC Mobile Country Code [default: 901]
-y MNC, --mnc=MNC Mobile Network Code [default: 55]
-m SMSC, --smsc=SMSC SMSP [default: '00 + country code + 5555']
-M SMSP, --smsp=SMSP Raw SMSP content in hex [default: auto from SMSC]
-s ID, --iccid=ID Integrated Circuit Card ID
-i IMSI, --imsi=IMSI International Mobile Subscriber Identity
-k KI, --ki=KI Ki (default is to randomize)
-o OPC, --opc=OPC OPC (default is to randomize)
--op=OP Set OP to derive OPC from OP and KI
--acc=ACC Set ACC bits (Access Control Code). not all card types are supported
-z STR, --secret=STR Secret used for ICCID/IMSI autogen
-j NUM, --num=NUM Card # used for ICCID/IMSI autogen
--batch Enable batch mode [default: False]
--batch-state=FILE Optional batch state file
--read-csv=FILE Read parameters from CSV file rather than command line
--write-csv=FILE Append generated parameters in CSV file
--write-hlr=FILE Append generated parameters to OpenBSC HLR sqlite3
--dry-run Perform a 'dry run', don't actually program the card
The source code is available.
Also the SIM card is just a smart card. You can use pyscard or pyusb to operate on it. I found this Q&A helpful.
I'm working currently on a small microhpone, connected to PC via an FPGA. The FPGA spits a raw datastream via UART/USB into my computer. I'm able to record, play and analyze the data.
But I can't play the "live" audiostream directly.
What works is saving the datastream in PCM raw-format with a custom made C-program, and piping the content of the file into aplay. But that adds a 10sec lag into the datastream... Not so nice for demoing or testing.
tail -f snd.raw | aplay -t raw -f S16_LE -r 9000
Does someone have another idea, how get the audiostream faster into my ears? Why does
cat /dev/ttyUSB0 | aplay
not work? (nothing happens)
Thanks so far
marvin
You need an api that lets you stream audiobuffers directly to the soundcard. I haven't done it on Linux, but I've used FMOD for this purpose. You might find another API in this question. SDL seems popular.
The general idea is that you set up a streaming buffer, then your c program stuffs the incoming bytes into an array. The size is chosen to balance lag with jitter in the incoming stream. When the array is full, you pass it to the API, and start filling another one while the first plays.
That would seem to be the domain of the alsaloop program. However, this program requires two ALSA devices to work with and you can see from its options that it goes to considerable effort in order to match the data flow of the devices, something that you would not necessarily want to do yourself.
This Stackoverflow topic talks about how to create a virtual userspace device available to ALSA: maybe that is a route worth pursuing.