hardware – Page 2

[Import]Understanding JCOP: pre-personalization

Posted on September 4, 2017 - September 10, 2017 by Kamil (aka. v3l0c1r4pt0r)

NOTE: This post was imported from my previous blog – v3l0c1r4pt0r.tk. It was originally published on 25th July 2017.

As I promised some time ago, now I am going to describe process of pre-personalization of a JCOP card. JCOP is one of the easier to get JavaCard-compatible cards. However they cost a bit. The problem with the ones available from eBay sellers is lack of pre-personalization. Ok, there are some advantages of buying not pre-personalizaed card, like ability to set most of its parameters, but by the way it is quite easy to make such card unusable.

Online resources, as I mentioned in the first part of the tutorial, are not very descriptive. They say that there is such thing like pre-personalization and it has to be done before using the card, flashing applets, using them and so on. There is only one source that helps a little bit. Someone has written script for the process. However there are two problem with the script. The first one is that it is written in some custom language and internet does not know about the interpreter, it is probably something provided by NXP – manufacturer of JCOP for its customers and neither me nor (probably) you, reader, are their customers. The consequence is that we can have script in custom language, with commands like ‘/select’ or ‘/send’. Fortunately, documentation of ISO 7816 (smart card connection), allows to decipher this. So this problem could be finally solved. Another problem is lack of command values and addresses in memory, so we do not know where and how to read/write/execute anything. After really deep search in Google, finally, I was able to find out all the missing values, so this tutorial could be written.

Process overview

Ok, after this way too long historical introduction, let’s see what will be needed. I assume, you are already able to communicate with your card using raw PDUs. If you don’t, up to this point there are quite a few resources to learn from, so I will not describe this. The most important thing here is to have so called transport key (K_T). If you do not have it, go get it now. Seller should provide it to you, and if he did not, you are stuck, since the first step requires this key.

So, basically steps will be as follows:

Select root applet with Transport Key
Boot the card
Read/write some data
Protect the card
Fuse it

Easy? Easy. But only if you know some hex numbers. Ok, here, one big WARNING: the last step is irreversible and can be done by mistake quite easily, so think twice before sending anything, and if you are sure, that you are done, think twice again, before issuing it.

Pre-personalization, step by step

At first, we use Transport Key to select proper applet. Format of SELECT command is as below:

CLA=00 INS=A4 P1=04 P2=00 Lc=10 (...)

Where CLA is always zero, INS means SELECT, P1, according to ISO7816 means selection by DF name and Lc is length of K_T. After that, key have to be appended. Of course, whole APDU is to be given to communications program as binary values or hex values only.

What now follows is specific to NXP cards only and is mostly undocumented publicly. First of such commands is BOOT command. Its format is as follows:

CLA=00 INS=F0 P1=00 P2=00

Now double care have to taken, because FUSE command should be available after this point and its APDU consists only of zeros, so every mistake might make the card unusable, since security keys are generated randomly for each card.

Reading memory

Now the most important values to read are called CM_KEY and GPIN in memory dump, I shared in the previous post on the topic. First one starts at offsets: 0xc00305, 0xc00321 and 0xc0033d and are 0x10 bytes long. The other one can be found at offset 0xc00412 and by default should be 5 bytes long. However maximum length is also 0x10, so it is better to make sure the length is really 5 by reading byte at offset 0xc00407. To sum up following commands need to be issued and results be saved for future use:

CLA=C0 INS=B0 P1=03 P2=05 Lc=10
C0 B0 03 21 10
C0 B0 03 3D 10
C0 B0 04 07 01
C0 B0 04 12 xx

Where CLA + P1 + P2 is concatenated address of memory area to read, INS=B0 is read command and Lc contains length of data to read.

Writing data

Alternatively, it is possible to write custom values to these buffers. This is especially encouraged for users who want to use the card not only for testing. Overwriting the values could be done with following:

CLA=C0 INS=D6 P1=03 P2=05 Lc=10 (...)
C0 D6 03 21 10 (...)
C0 D6 03 3D 10 (...)
C0 D6 04 12 05 (...)

Where user data is filled with some random data of length in Lc field.

Required values

Beside securing keys, it is required to set CM_LIFECYCLE value to 0x01 and make sure all fields related to keys and PIN have proper values. Here, my memory dump can be used as reference, since I initialized the card before dumping the memory.

Finishing

After setting all the fields to desired values, there are two more steps to do. First one is issuing PROTECT command. It looks as below:

CLA=00 INS=10 P1=00 P2=00

And finally, sending FUSE command with:

CLA=00 INS=00 P1=00 P2=00

Here again, remember, that this command cannot be undone!

Well done! Your card should now be pre-personalized and ready to use, even in production environment. At the end, one remark: probably FUSE command does not need to be issued at all. However, if it is not issued, the card is completely insecure and should not be used in production.

Previous part of this tutorial can found under this link.

[Import]Understanding JCOP: memory dump

Posted on September 4, 2017 - September 10, 2017 by Kamil (aka. v3l0c1r4pt0r)

NOTE: This post was imported from my previous blog – v3l0c1r4pt0r.tk. It was originally published on 8th February 2017.

Some time ago I was struggling with JCOP smart card. The one I received as it turned out was not pre-personalized, which means some interesting features (like setting encryption keys and PIN) was still unlocked. Because documentation and all the usual helpers (StackOverflow) were not very useful (well, ok, there was no publicly available documentation at all), I started very deep search on Google, which finished with full success. I was able to make dump of whole memory available during pre-personalization.

Since it is not something that could be found online, here you have screenshot of it, colored a bit with help of my hdcb program. Without documentation it might not be very useful, but in some emergency situation, maybe somebody will need it.

JCOP memory dump made at the very beginning of pre-personalization

Small explanation: first address, I was able to read was 0xC000F0, first address with read error after configuration area was 0xC09600. I know that, despite of lack of privileges some data is placed there.

There are three configurations: cold start (0xc00123-0xc00145), warm start (0xc00146-0xc00168) and contactless (0xc00169-at least 0xc0016f). Description of coding of the individual fields is outside of the scope of this article. I hope, I will describe them in future.

Next time, I will try to describe the process of pre-personalization, that is making not pre-personalized card, easy to get from usual sources of cheap electronics, able to receive and run applets.

Update: Next part of this tutorial can be found under this link.

[Import]Airlive WN-151ARM UART pinout & root access

Posted on September 4, 2017 - September 7, 2017 by Kamil (aka. v3l0c1r4pt0r)

NOTE: This post was imported from my previous blog – v3l0c1r4pt0r.tk. It was originally published on 24th November 2015.

For curious ones. Here is pinout of serial connection. As you can see UART pins are at J4 header (should have pin 4 labeled and 1 be square).

J4 header
Num.	Function
1	VCC
2	RX
3	TX
4	GND

Edit: Oh, and one more thing: goldpin header, you see in the picture is soldered by me, so do not be surprised if you have to hold wires all the time during the transmission.

Root access

There is also possibility to gain root access without removing the cover and possibly voiding the warranty. You have to connect to router’s AP and enter

http://192.168.1.254/system_command.htm

into your browser (panel authentication required). Now you can execute any command you want with root privileges! So let’s type

/usr/sbin/utelnetd -d &

into Console command field and press Execute button. If everything went well, you should now be able to connect to your router using telnet at its default TCP port 23. After that you should see BusyBox banner and command prompt.

It is worth noting that this hidden console cannot be accessed by unauthorized person, so only router administrator can use this (in theory, in practice there are surely a lot of routers using default credentials and security of httpd binary is unknown).

[Import]TP-Link TD-W8901G UART pinout

Posted on September 4, 2017 - September 7, 2017 by Kamil (aka. v3l0c1r4pt0r)

NOTE: This post was imported from my previous blog – v3l0c1r4pt0r.tk. It was originally published on 31st May 2014.

Some people might wonder: what is the pinout of my router’s serial connection. If you’re a happy owner of TP-Link TD-W8901G and asking that yourself, here is the answer:

In the link below there is also this router’s pinout and moreover author states that to make that port working there is a need to modify some resistors. I have V3.5 of that router and didn’t notice any mod to be necessary.

It is possible to solder goldpins in here and router so far haven’t fried. Of course you can try communicating without stable connection and it even works but after training your fingers while waiting for the firmware download/upload to complete you’ll change your mind, I guarantee:).

PS: that model is the one that was one of the victims of massive DNS changing some time ago so if this is the one you’re using as your bridge to the Internet you may be also interested in this.

PS2: if you have another router and want to find out what is the serial port pinout I recommend going here.

[Import]Graphic LCD based on ST7565 chip under Raspberry Pi

Posted on September 4, 2017 - September 7, 2017 by Kamil (aka. v3l0c1r4pt0r)

NOTE: This post was imported from my previous blog – v3l0c1r4pt0r.tk. It was originally published on 25th December 2013.

Hi, today I’d like to show you how to connect and use gLCD module with Raspberry Pi as host. The display I have is only bare display without any board not like the one in Adafruit’s offer. It can be powered by 3V3 Raspberry but the display itself needs a bit more power so we will need a few capacitors to build a circuit for that purpose. It will also make the connection a bit complicated (can be seen in the photo on the right). Nevertheless I think that the process is still rather easy.

Overview

As far as I know ST7565 based displays can be connected on two ways: parallel and serial. In case of serial connection, which I used to save few GPIO’s, it is possible to program it using SPI or just only GPIO’s. The display that I have is a bit different than most of the others because it has external backlight, which is additionally single LED so it is very power-saving (15mA). The only problem with that backlight was that the vendor didn’t told anything about parameters of that diode so I needed to figure it out myself.. The second problem while connecting the display itself might be amount of cables that need to be connected when using breadboard. Despite these two facts the whole process should be easy.

Physical connections

As said before the only step that may be a bit complicated is connecting so called step-up voltage circuit, made of 4 capacitors. The capacitors that we will use are 1uF electrolytic caps. Beside that we need to use another 5 caps (same as before) to connect parallel inputs to ground. So in sum we need 9 of them. Now we only need to connect VDD to 3V3 pin on Raspberry, ground from the schematic on the right with GND pin, SDATA to SMOSI on Pi, SCLK to SCLK and A0, RST and CS to any free GPIO. It is good to remember their numbers cause we will need it in a moment 🙂 It is important to use numbers used by Linux kernel, not wiringPi which has its own names. At last we need to connect the backlight. As said I have ECO backlight so I had to connect mine using 10 Ohm resistor. You can connect it to 3V3 or if you like to have control during runtime use GPIO, just like any other LED.

Configuring the program

Now I have to mention something about a program itself, because depending on how your vendor implemented the things your display will almost surely need a bit different settings. General procedure will look the same on every ST7565-based display. Main differences will be on particular commands during setup procedure.

 
uint8_t init() 
{ 
  if (!bcm2835_init()) { 
    return 0; 
  } 
  bcm2835_gpio_fsel(LCD_BACK,BCM2835_GPIO_FSEL_OUTP);   //backlight 
  bcm2835_gpio_fsel(LCD_A0,BCM2835_GPIO_FSEL_OUTP);   //A0 
  bcm2835_gpio_fsel(LCD_RST,BCM2835_GPIO_FSEL_OUTP);    //RST 
  bcm2835_gpio_fsel(LCD_CS,BCM2835_GPIO_FSEL_OUTP);   //CS 
  bcm2835_gpio_write(LCD_CS,HIGH);        //set CS to high to indicate the bus as free 
  bcm2835_gpio_write(LCD_RST,LOW); 
  bcm2835_delayMicroseconds(1); 
  bcm2835_gpio_write(LCD_RST,HIGH);       //hardware reset 
  //setup SPI 
  bcm2835_spi_begin(); 
  bcm2835_spi_chipSelect(BCM2835_SPI_CS_NONE);      //manual CS control 
  bcm2835_spi_setClockDivider(BCM2835_SPI_CLOCK_DIVIDER_4); //set speed to 62.5MHz (fastest supported) 
 
  int i; 
  bcm2835_gpio_write(LCD_CS,LOW); 
  for(i = 0; i < sizeof(initcmd)/sizeof(uint8_t); i++) 
    transfer(initcmd[i],0); 
  bcm2835_gpio_write(LCD_CS,HIGH); 
  bcm2835_gpio_write(LCD_BACK,HIGH);        //turn backlight on 
 
  return 1; 
}

I think that the code above should be generally clear. The most important for us is for loop that is executing every byte from initcmd array. Its content will look like that:

const uint8_t initcmd[] =
{
  0xa1,             //screen orientation
  0x41,             //set starting line
  0xc0,             //page count direction
  0xa3,             //1/7 bias
  0x2c,             //vc
  0x2e,             //vc+vr
  0x2f,             //vc+vr+vf
  0x24,             //voltage regulator (0x20-0x27)
  0xa6,             //do not reverse the display
  0xaf,             //display on
  0xa4,             //display from ram
  0x81,             //turn on brightness regulation
  0x18              //set brightness (0x0-0x40)
};

The most important values here are:

voltage regulator – 0x20 means the darkest, as seen above in my case 0x24 worked
bias – I saw displays that had 1/9 so you need to make sure how is in yours and set it according to chips documentation linked at the end

You may also want to play with commands like screen orientation, page direction, display reverse or brightness to fit them to your needs. Now you have tell the program which GPIO you used as backlight (if you weren’t using GPIO you will now need to comment out few lines that sets backlight up), CS, RST and A0.

The program itself

To compile the program you will need to use external library named libbcm2835. It can be installed on ArchLinux ARM by issuing pacman -S libbcm2835 as root. If you are ready you can compile the program by typing: gcc -o lcd lcd.c -lbcm2835 assuming you didn’t change the filename. The simple program I’ve written, basing on the one posted on Gist by tmeissner here and ST7565’s documentation supports transferring single byte (commands too), whole framebuffer, or writing 5×8 single ASCII character or character string. Basing on both codes: mine and Meissner’s I think it is possible to do anything you could think about with that display.

Font creation

Standard ASCII table and traditional ‘Hello World!’:)

Ending slowly it’s time to tell something about fonts. As I said it is possible to simply write characters on the screen. To understand how all that thing works you need to know how the pixels are transfered to the display. The best explanation of the ST7565 display’s work can be in my opinion found here. TL;DR: the whole pixel space is divided into eight, 8-pixel high, horizontal pages divided into 128 columns that are 8 pixels high. If you didn’t understand, try link above. Nevertheless single letter is 8-pixel high and 5-pixel long so we need 5 bytes to store one letter. Its pixel map starts at left, top corner so it’s our (0,0) point and setting LSBof the first byte lights highest pixel. The font that is available in the code is Fixed 5×8 if someone is curious, it’s one of the default fonts in Xorg. To speed up conversion of the font to the display’s format I made simple OpenGL program to do the job for me. The code is of course available to download (check out my github).

DLs

Traditionally, at last some downloads:

First, and most important: C code of my program
ST7565 documentation can be found here

[Import]Using GNU Radio Companion – simple FM radio tutorial

Posted on September 4, 2017 - September 6, 2017 by Kamil (aka. v3l0c1r4pt0r)

NOTE: This post was imported from my previous blog – v3l0c1r4pt0r.tk. It was originally published on 1st November 2013.

This post is the second part of the Instructable mentioned on the previous post. That’s tutorial on how to make simple FM radio using GRC. That task is in my opinion the simplest project that can be made using GRC so it’s in fact beginners guide to GNU Radio which is really capable software. I hope that it is only the first my project using that software.

It isn’t hard to find GRC projects that implements FM radio functionality, that’s a fact. But when it comes to reproduce them so they are working just like SDR# you’d realize it’s a bit harder task. At least I did. I found about a three such projects but there was never any included project file and the only materials was video or pictures. I admit the video has pretty good explanation but it still wasn’t enough. The rest was even worse. They were only blog posts with few screen shots and short description. So finally to reproduce functionality of SDR#’s FM radio I had to think on my own. And after few hours I did what I tried to do.

A bit of theory

But let’s start at the beginning. The first thing that you need to do to start creating your own FM receiver using GRC is to find FM station that can be received without disruptions so you can check if your program works as well as i.e. SDR#. It can be done with help of SDR# and when you found one you are ready to learn some theory about FM signal processing. In fact it could be omitted, but in my opinion it is better to know a bit. I personally am not any specialist in radio theory so it will be really simple and I might be wrong somewhere so if you find any mistake in that what I will write here just let me know in comments.

The simplest FM radio consists of few elements:

signal source – in our case it would be RTL-SDR dongle
low pass filter
WBFM demodulator
audio output – your PC’s sound card

There can be few other elements depending on input and output sample rate, if it will be possible to match them using only above elements there won’t be any other. So our task will be getting signal using RTL-SDR, passing it through low pass filter and FM demodulator and outputting on PC’s sound card. Meanwhile we will also need to match the sample rate of the input to the one of the output (2 MHz in to 48 KHz out). All elements of this circuit can be found by writing part of its name while list on the right is selected. Element’s names are the ones used as section header below.

RTL-SDR source

Our signal input. We need to set its sample rate to 2M. It can be done by editing samp_rate variable and setting its value to 2e6. We need also to set the frequency of the station we want to receive. It is good practice to add every value that might be changed in the future as standalone variable. This can be done by adding Variable block from Variables category or, if you want to have possibility to edit it during the runtime block named WX GUI Slider or WX GUI Text Box and then just writing variable name as value in block’s properties.

Rational Resampler

Now we need to convert sample rate from 2M (samp_rate) to 500K which I realized is the best value for low pass filter’s input rate. To do that we need to add another variable, named i.e. quadrature, set its value to 500e3 (means: 500K). With that we need to add rational resampler’s block and set its decimation value to int(samp_rate/quadrature). Of course its input on the schematic should be connected to output of RTL-SDR Source (can be achieved by clicking on blue out on one block and then blue in on another).

Low Pass Filter

The next step is to filter out frequencies other than the one we centered in th previous step. In that task we will use a low pass filter block. We here set cutoff frequency to 100e3. This is because that’s standard band’s width. I don’t know what correct value for transition width should be, but trying to change that I found that the higher value the better so it’s finally set to 1M. Obviously it should be connected to resampler’s output.

WBFM Receive

Now we could do the nearly final and the most important step: placing the FM demodulator. In my case its quadrature rate equals 500k (that’s the same value as before so I set this to the value of quadrature variable). I don’t know if it could be changed to something else so if you are not sure just leave it as is. In that setting it should work.

Next Rational Resampler and Multiply Const

These elements’ job is to match the signal’s rate to the one supported by sound card and provide volume regulation. At first we need to convert rate from 500k to 48k so we need to decimate by 500 and then multiply by 48. In the second block we set const to volume. Now we can create variable or place WX GUI Slider with variable name set to volume. As you can see here color of WBFM demodulator is different than rational resampler’s and multiplier’s in and out. To change that you need to select them and use up and down arrows on your keyboard.

Audio Sink

That one’s function is to output signal on our sound card. Now its only required to edit its rate and choose 48k from a drop down list and that’s it! If you don’t have that option just choose the biggest value and edit value in rational resampler and it should work. Now you should be able to execute your program and test if it works. To hear anything it will probably be required to increase volume to about 50.

Finally: some links

If you don’t know how some part has been done or what value should have a particular variable below you can download projects that I’ve made first learning to use GRC myself and then preparing this tutorial. There is one project presented here and one made earlier.

[Import]RTL-SDR under Arch Linux – getting started

Posted on September 4, 2017 - September 5, 2017 by Kamil (aka. v3l0c1r4pt0r)

NOTE: This post was imported from my previous blog – v3l0c1r4pt0r.tk. It was originally published on 1st November 2013.

First post about hardware was to be something different. Unfortunately it looks like that project already failed so it probably will never be published. Instead I’m starting, I hope series of posts, about cheap Software Defined Radio dongles based on RTL28xxU chips. This post will be short introduction to the topic of RTL-SDR and it will mostly be the same as my Instructable here.

If you get here I imply that you already know what SDR is. If you don’t take a look at Instructable linked above. Getting one is for yourself should be easy. There are lots of offers on ebay that have names of chips included in the title so you should just search for rtl-sdr and i.e. R820T. That chip is one of the most capable and cheap in contrast to E4000.

Installation

The only things we will need here is some Linux distro and of course a tuner. As Linux I recommend Arch, because of availability of packages required and simplicity of its installation. There would be good if you have better antenna for the tuner and in that case you should also have adapter to standard antenna connector.

If you are ready you can now connect your dongle to PC and check using dmesg | tail or journalctl if it is has been detected by your system and if it contains appropriate chips.

If you chose the one with R820T it is probably required to disable default dvb_usb_rtl28xxu drivers, because, at least in my case, after disconnecting the dongle system hangs and the reason is for sure fault of that particular driver. You can disable it by creating new .conf file in /etc/modprobe.d directory. It could be done i.e. by typing # nano /etc/modprobe.d/blacklist.conf in console. The file should contain one line: blacklist dvb_usb_rtl28xxu. You also need to add that file to FILES variable in /etc/mkinitcpio.conf so it looks like that:FILES=”/etc/modprobe.d/blacklist.conf” and generate new initrd file by using # mkinitcpio -p linux. Now after restarting your computer everything should be OK.

Now we will need to install few packages to make RTL-SDR up and running. rtl-sdr and sdrsharp-svn are needed for basic functionality. You probably also want to install gnuradio and gr-osmosdr-git to make more advanced things like analysis of digital signal transmitted at 433 MHz. rtl-sdr is the main driver and can be installed on Arch from community repo:

# pacman -S rtl-sdr

There is also its git version available on AUR as rtl-sdr-git. SDR# is the program that offers basic capability to decode FM and AM radio and have easy to learn GUI so using it is the best for beginners. It is available on AUR as sdrsharp-svn.

The most capable software for RTL-SDR is GNU Radio and its graphical tool: GNU Radio Companion. It is also available on AUR (name: gnuradio). It is also required to install package gr-osmosdr-git from AUR in order to use RTL-SDR dongle as source in GRC. Its usage tutorial is available in the next post and as continuation of Instructable mentioned at the beginning of this post.

Now if you already installed all the required software you can try to find a radio station at about 100 MHz to check if everything is working fine. As mentioned earlier you could be able to listen to only the strongest stations on the default antenna. Finding one good signal will be useful in the next tutorial. At the end I’m enclosing screenshot of SDR# with settings proper to receive FM station.