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.
NOTE: This post was imported from my previous blog – v3l0c1r4pt0r.tk. It was originally published on 24th November 2015.
Airlive WN-151ARM pinout
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).
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:
TP-Link TD-W8901G’s pinout
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.
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
Connected display
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
Connection scheme
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()) {
return0;
}
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 onreturn1;
}
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:
constuint8_t initcmd[] =
{
0xa1, //screen orientation0x41, //set starting line0xc0, //page count direction0xa3, //1/7 bias0x2c, //vc0x2e, //vc+vr0x2f, //vc+vr+vf0x24, //voltage regulator (0x20-0x27)0xa6, //do not reverse the display0xaf, //display on0xa4, //display from ram0x81, //turn on brightness regulation0x18//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).
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
RTL-SDR Source Properties
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
Low Pass Filter Properties
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
Volume slider Properties
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.
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
SDR# receiving FM station
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.
