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.
Related
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.
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
We are trying to transfer file using minicom (in host pc) and picocom(in arm based evaluation board) combination.
On evaluation board side we have /dev/ttygserial and on host pc side we have /dev/ttyUSB0.
Host side minicom setup is as follows,
Serial device - /dev/ttyUSB0
Baud Rate - 115200
Steps to set minicom in receiving mode.
press ctrl+a R , select zmodem.
Now minicom will start waiting for file from other end.
On evaluation board side we use picocom as follows to send the file.
On command line execute picocom -b 115200 -s "sz -vv" /dev/ttygserial
Now press Ctrl+A and Ctrl+S.
Picocom will ask for filename by printing **file
Once file name is provided and enter is pressed file is sent to host.
All this steps works and we are able to transfer different types of files from evaluation board to pc but now we want to put this procedure into C code. For that I have following doubts,
Is it possible to set minicom in file reception mode using single command? (meaning noninteractively) ?
Is it possible to send file using picocom in single command (meaning noninteractively)?
Any other suggestions?
In other sites also people have asked this kind of question but questions unanswered yet.
So I decided to look into picocom code and found that it is very simple to make a change in that code.
I have made send command non-interactive, I will make receive command too non-interactive and post full code here so that it can be referred by anyone who has a similar problem.
When I use Minicom to capture data from a serial port, I need to save the big data into a file, named minicom.cap. However, if I press Ctrl+A and L to capture file, it failed. No file was created (minicom.cap did not exist beforehand). My download directory was properly created. My OS is Mint, and I read data from Arduino nano v3.0
Did you try to start minicom as
minicom -C capturefile
Unless i got something wrong, it should start to capture incoming data immediately.
OP might miss step "Shift + L" after writing, so the overall procedure is as below:
1 (inside minicom)
2 Ctrl A + Z
3 Shift + L
4 (wait for writing ... )
5 Shift + L
6 (check the file you have written, default is minicom.cap, you may want to find it at /root/minicom.cap)
chown root:dialout /etc/minicom/minirc.dfl
chmod 664 /etc/minicom/minirc.dfl
Now any member of the dialout group can write to minirc.dfl
minicom needs a configuration file that is under root permissions and is stored at /etc/minicom/ and is named minirc.dfl.
Usually when you first run minicom for the first time, as sudo, you can save the minirc.dfl, as if you run as any other user it will not save.
That may be your problem.
This is a little more than the scope of the question calls for but as it has already been answered, I thought somebody might like to do things a little user friendly.
You might be interested in this if you frequently open up a serial connection to multiple devices. You can do this with desktop shortcuts.
I use this for switch and router connections, I have two different console cables, a USB to mini USB and also a db9 with USB A adapter to rj45.
Using the shortcuts here means I don't need to manually reconfigure minicom every time I want to switch devices. The shortcuts give the correct configuration file as a parameter (identifier) as well as the capture file (-C). All i need to do it make sure my devices are connected to my computer with the cables.
If this is something you could use, run these commands as a normal user from your terminal (not from minicom). The configuration files will be saved to your home directory where minicom can find them.
Make a log file directory: You might choose to just log in /var/log but I want quick access to the log files.
mkdir ~/minicom
Find your device:
dmesg | grep tty
If your cable uses an RS-232 chip such as some usb to mini usb console cables, your tty device will likely be on ttyACM* and not ttyUSB*
Create the minicom configuration file using nano. Adapt the capitalised parts to fit your needs, baudrate may be set incorrectly if you get quirky characters or no output. You may create as many as you need along with the desktop shortcuts. just change the identifier.
nano ~/.minirc.IDENTIFIER
pu port /dev/ttyDEVICE
pu baudrate 9600
pu rtscts No
pu logfname /home/USER/minicom/IDENTIFIER.log
Create a desktop shortcut.
nano ~/Desktop/IDENTIFIER.desktop
[Desktop Entry]
Encoding=UTF-8
Name=Minicom IDENTIFIER
Comment=Something relevant to your connection/device name maybe
Exec=minicom IDENTIFIER -C/home/USER/minicom/IDENTIFIER.log
Terminal=1
Type=Application
Make it executable
chmod +x ~/Desktop/IDENTIFIER.desktop
That's it now test the connection, double click your new shortcut.
A note about the IDENTIFIER part, it can be anything. a router or switch model, a device name or type. Do what suits you but maybe use hyphens instead of spaces, I've not tested that but i would imagine they would cause issues such as only getting the name before the first space or worse, attempting to load multiple minicom.identifier files.
Once you have created your first connection, open another terminal:
tail -fn25 ~/minicom/IDENTIFIER.log
Because you have set minicom to capture output, by tailing the log/capture file you can scroll back as far as you need should you be running things with lengthy output, It can be useful for configuration files in routers/switches for example which can be thousands of lines long. Just scroll to the part you are working on in the tailed file to use as a reference while you make changes in minicom, the tail terminal will still collect data but will not automatically jump back to the new line as minicom does when you star to type.
If somebody more shell savvy than myself would like to add to this to make a shell script that accepts the required parameters for setting up a new connection profile,logs etc I wouldn't be too upset about it :)
As an aside, I wanted to add a command prior to minicom running in the shortcut to apply a title to the terminal window using the identifier, I could not get this to work in Ubuntu 20.04 at the time of this posting.
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.