Sunday 27 April 2014

Activities

Looking forward to a busy few weeks, InfoSec is from the 29th April to the 1st May and I will be on the IT Governance stand on the 30th April to talk about PCI, Pen Testing and the Technical Services that IT Governance offer. My technical services colleagues will be on the stand on the other days, if you can't make the Wednesday, they will be more than happy to talk to you about your requirements. 

As part of the events related to InfoSec, I am looking forward to the ISSA-UK Infosec drinks on the Tuesday and the Information Security Bloggers meet-up on Wednesday evening where IT Governance Blog to which I contribute has been nominated for Corporate Blog of the year. 

I will also be attending two other PCI events in London during the week, including the “PCI SSC Assessor session London 2014” on Friday 2nd May. 

The following week I am speaking at the “ISO27001:2013, PCI DSS v3 and CES v1.0: New standards in the global cyber war” at the Churchill War Rooms, London. There are still some spaces left if you wish to attend, see the events page at the IT Governance website or book at the IT Governance stand at InfoSec next week. I will be speaking in the afternoon on Security as “‘Business as Usual’ - a recommendation of the PCI DSS v3” in that compliance is not a once year event but part of your everyday work practices. 

Final on the 13th May at the University of Bedfordshire, Polhill campus in Bedford I am giving a talk for the Bedford BCS branch and the IET Bedfordshire and Hertfordshire section on hacking the Internet of Things, if you are interested please book via the BCS event site.

If you are at any of these events I look forward to meeting you.

Monday 21 April 2014

Hacking a door controller

As part of looking at RFID and the Internet of Things. I decided to look at RFID Door Access Control Systems and how they could be compromised. I wanted to show it is relatively easy to capture the RFID tags data and be able to clone them.

ADM2000-M Door access controller


The use of the Access Door Controller as a RFID sniffer was based on the work done by Kevin Bong, owner of the MiniPwner website and his minipwnerrfid article. Kevin's article describes an early version of the AD2000-M door controller than is currently available.

I used a AD2000-M access controller with an "Access Control V3."0 circuit board, which used a Nuvoton w78e052ddg 8-bit microcontroller, there is also an unidentified "ID module" attached to the circuit board. The ID module had a number of inputs and outputs which are labelled as follows.

GND OUT DR CFE VCC
GND CY ANT2 ANT1

Pins from the module were traced back to the Micro-controller pins 15 and 16, pin 16 was identified by Kevin in his article as being transmitting the captured TAG details to the Micro-controller. By sniffing this signal it is possible to read the submitted Tags serial numbers.
Part of AD2000-M Circuit - showing test pins
This is indicated that although the circuit board was visibly different from that in Kevin's article, the sniffer software should work. As the signals passed through, what looked like a set of unpopulated test pins, I soldered a set of pins to the board to make easier to connect to the circuit board.

Location of unpopulated test pins
Underside of the circuit board with header soldered in place
Header soldered to the circuit board
After soldering the header to the circuit board the GND and Out connections were connected to the Arduino as per Kevin's article

Header pins connected to a breadboard
Arduino connected to the Access Control unit
The Arduino sketch from Kevin's web site was uploaded to the Arduino and the serial monitor used to capture the scanned tags.
Serial Monitor display showing captured TAG numbers.
The next part of the project will be to clone or spoof the RFID tags.


Talk: Hacking the Internet of Things

I will be giving an introductory level talk titled Hacking the Internet of Things on Tuesday 13th May, details are available on the Bedfordshire branch of the BCS.

http://www.beds.bcs.org.uk/events.php

If you wish to attend you need to pre-book using the BCS event booking system https://events.bcs.org/book/1063/

Description of the talk

The Internet of Things describes a paradigm of how electronic devices including everyday items are now interconnected by various media to each other locally and across the Internet. This allows them to exchange information and to interact with us in order to make life easy. You can now control the heating in your home from a smart phone app or monitor the movement of hundreds of buoys free floating in ocean currents from anywhere in the world.

RFID Controlled Door lock
The Internet of Things has great potential for aiding us. However the potential for malicious activities is just as great. This talk discusses the Internet of Things and its potential. This will be followed by discussions and demonstrations of how the Internet of Things can be hacked to reveal details of our interactions or to take control of the environment around us.

Friday 18 April 2014

SQL Injection, CISSP and Software Development

One of the topics of the CISSP is software development which covers the web application environment and vulnerabilities such as SQL Injection. SQL injection in its simplest form and the derivatives that have came about are probable the most effective attack tool in the hackers toolbox, whether black or white hat. The vulnerability is well know, as is the methods to mitigate the vulnerability, so why is there a problem? and why is the vulnerability still so effective.

A recent Ponemon study found:-

Measures to prevent SQL injection attacks are also lacking. Despite concerns about the threat, 52 percent do not take such precautions as testing and validating third party software to ensure it is not vulnerable to SQL injection attack. 

and that

44 percent of respondents say their organization uses professional penetration testers to identify vulnerabilities in their information systems but only 35 percent of these organizations include testing for SQL injection vulnerabilities. 

It also concluded

it used to require a high-level of expertise to construct a malicious query and conduct an SQL attack. Now the internet is flooded with tools that allow inexperienced individuals to obfuscate malicious queries, making it easy to be a bad guy, and even more difficult for SQL security measures to detect malicious queries.

The results are what I expected, I would a bit more into the detail and say the root cause of SQL vulnerabilities is the programming behind the applications. The developers don't understand SQL injection and don't know how to code to mitigate against such attacks.

History of SQL

The SQL injection has formally been around since Rain Forrest Puppy (aka Jeff Forristal) published papers in 1998 on the technique (http://phrack.org/issues/54/8.html#article). SQL Injection is as the name suggests a code injection attack used on data driven applications, such as web applications but can be used to attack any SQL database. In the attack malicious SQL statements are inserted into an entry field for execution when the page is submitted to the application.

Mitigating

The methods for mitigating SQL injection are well documented, the main methods are forms of input validation and restricting commands that can be run.

  • Parameterized statements
  • Enforcement at the coding level
  • Escaping
  • Pattern check
  • Database permissions

The Continuing problem

The problem is still very prevalent despite being widely known and methods of mitigating have been identified. The problem is prevalent in web applications; these are typically developed by coders who more experienced with design and usability issues than with business logic and server communication. Often tools and frameworks are used to develop application are using sophisticated front ends that auto generate code to drive the application, including the code to access databases.

In the past, I have hand coded applications using text editors as simple as notepad and used development environments such as Dreamweaver, which is not unique in its approach or particular bad, but the designer drags elements on to the screen, creates a layout and then enters details of the database to which it is to communicate and the code is generated automatically by the application to access the database.

My experience is that the application generated code is a lot more complex and larger than it needs to be to do the same function that I can write in a simple text editor. Further I find that web application developers and database application developers are not software engineers (programmers) and not trained in coding techniques in the same way. Often at University and colleges they will use examples of industrial applications for web and database front end development to give them experience of the tools they will use when employed before they really understand hand coding.

The problem with web applications will continue whilst developers are not aware of good secure programming practice and the tools used in development are not generating secure code.

Secure (Software) Development Lifecycle

A Software Development Lifecycle (SDL) is essentially a series of steps, or phases, that provide a model for the development and lifecycle management of an application or piece of software. The methodology within the SDL process can vary across industries and organizations, but standards such as ISO/IEC 12207 represent processes that establish a lifecycle for software, and provide a mode for the development, acquisition, and configuration of software systems. The intent of a SDL process it to help produce a product that is cost-efficient, effective, and of high quality. Once an application is created, the SDLC maps the proper deployment and decommissioning of the software once it becomes a legacy. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release, and maintenance (response). The maturity of the SDL can be measured with using a Software Assurance Maturity Model (SAMM) such as the OpenSAMM which has become part of the Open Web Application Security Project (OWASP).

Security is required to be consider all stages if security is to be built into the development rather than bolted on afterwards. If security is considered at the project initiation stage, it becomes part of the functional requirements, considered at the design stage, secure techniques will need to be used at the development stage and will be a requirement to be considered during testing and acceptance of the software. Microsoft have a good resource on Secure Development Lifecycle (https://www.microsoft.com/security/sdl/default.aspx) on their website.

Building security in, especially once the secure development lifecycle has matured will be easier and cheaper than trying to bolt on security after the functional testing has been completed.

Separation of testing and development

It is understand that developers are often not the best testers of a product, nor are end users. Both developers and end users will use cases they know will work or fail due to business logic and fail to use test cases that were not expected by the developers or expected when the functional requirements were generated. Testing application for functionality and security require two different approaches and less experienced the tester is the more likely they will not be able to test security requirements fully.

Applications should be written by developers who understand secure programming, then moved to a separate testing environment where security is tested as one of the acceptance criteria of the project by experienced testers. After certification and accreditation against the requirements, which include security, it is then moved into the production environment.

Open Web Application Security Project

The Open Web Application Security Project (OWASP) is a worldwide not-for-profit charitable organization focused on improving the security of software. OWASP  build documents, tools, teaching environments, guidelines, checklists, and other materials to help organizations improve their capability to produce secure code. It provides tools for developers and tester to use to develop and test secure applications and should be considered the first port of call for an organisation wishing know more about web application secure coding and how to test the security of an application.

Conclusion

To wrap this article I will reiterate that the root cause of SQL Injection vulnerabilities is poor application development caused by lack of secure programming knowledge by developers. During the initial phase of an application project security is not considered as part of requirement development, this causes security to be ignored at the other stages of the software development lifecycle.

Additionally lack of use of skilled tester in the testing stage is not identifying the vulnerabilities, allowing through into the production environment. Once into production the increased number of attacks by script kiddies using automated tools that obfuscate attacks make it hard for the application to be defended.

I would recommend

  • The use of a secure development lifecycle to build security into the development project as a functional requirement.
  • Auto-generated code should be reviewed by a skilled program, so it is optimised and to ensure security requirements are part of the functionality the code delivers.
  • The use of code review by experienced reviews who understand security requirements and secure programming practice. his can be done by 3rd parties and the use of tools to help with the analysis
  • Better education of web developers into secure programming techniques.
  • Organisations sourcing 3rd party developers need to check secure programming knowledge of those developers.
  • The use of skilled software testers to test the application for all vulnerabilities.



Wednesday 16 April 2014

Raspberry Pi and Serial Interfaces

A major use of the Raspberry Pi (RPi) is interfacing with the real world and other computers and often the communication takes place over a serial interface. I have written this as a result of my playing with the Raspberry Pi and using it connect to other devices. Please note this blog has used information from a number of sources in its compilation and I have not set out to plagiarise anyone but rather together information I found useful into a single source.

The RPi has a number of options for connecting to other devices including a serial interface using a universal asynchronous receiver/transmitter (UART) over the General-purpose input/output (GPIO) interface. The UARTs is used with communication standards such as EIA, RS-232, RS-422 or RS-485. The universal indicates that the data format and transmission speeds are configurable. The electric signalling levels and methods (such as differential signalling etc.) are handled by a driver circuit external to the UART. The GPIO on the Raspberry Pi is used to provide an interface to the world, it provides the following functionality through the double row of 26 pins.

  • Genuine GPIO (General Purpose Input Output) pins - 
  • I2C interface pins 
  • SPI interface, a similar concept to I2C but a different standard
  • Serial Rx and Tx pins for communication with serial peripherals
The Serial Peripheral Interface (SPI) bus is a synchronous serial data link, that operates in full duplex mode. It is used for short distance, single master communication, for example in embedded systems, sensors, and SD cards.Devices communicate in master/slave mode where the master device initiates the data frame. Multiple slave devices are allowed with individual slave select lines

I2C (Inter-Integrated Circuit) is a multimaster serial single-ended computer bus. It uses only two bidirectional open-drain lines, Serial Data Line (SDA) and Serial Clock Line (SCL). The I2C reference design has a 7-bit or a 10-bit address space.

I will be looking at uses of SPI and I2C later in another posting.

Signalling levels

Different signalling technology uses different voltages to indicate a logical '1' or '0', along with different device designs. For example RS232 uses a signal between +3v and +25v for a '1' and -3v and -25v for a '0' and RS485 uses a voltage differential.

Device Logic '1' Logic '0'
RPi +3.3v 0v
Arduino(*) +5v 0v

(*) Most Arduino are 5v, a few may be 3.3v

When using sensors for the Arduino with the RPi then you need to care with the signal voltages to prevent damage to the RPi.

Voltage warning

The RPI although having a 5V supply operates on 3.3v and connecting devices that use other voltages can damage the RPI board and components. Care must be taken when interfacing to other devices. The signalling voltages can damage the RPi and in particular if a power feed is used from another device this can damage the RPi as well.

When interconnecting devices and sensors to the RPi, care is required to ensure compatible voltage levels are used, and if necessary if voltages levels cannot be matched a logic level converter might be required such as the Sparkfun Logic Level Converter https://www.sparkfun.com/products/11978, I have a number of these myself and I do recommend them, however there are other devices and other methods of connecting different signalling voltages.

Powering the RPi through the GPI

It is possible to supply a 5v power connection on the GPIO pin. BUT, it has no backward protection and it was not really designed to be a 5volt input pin. The 3.3v pin can also be powered with 3.3v as the regulator has build in protection, but again it leaves your BCM2835 unprotected! Typically any power pins on GPIO area are used to power extended circuits.

Often this will be done as part of building a headless node (no keyboards, mouse or monitor) allowing the RPi to be powered via a serial interface or other connection.

One man's TX is another man's RX

I have often seen comment that when people have connected TTL to USB leads they had to switch the signal leads around. When connecting devices and leads together you can't just connect the labels. It needs a bit of thought.

A Transmission (TX) needs to be received (RX) and for two way communication, the remote TX needs to be connect to the local RX, this requires a crossover in the connection.


This can be combined with a logic level converter, when connecting pay attention to the direction of signal possible through the logic level converter, some channels may be unidirectional, others may be bidirectional.



RPi and 2 slices of serial

The RPi can use the serial connection in two modes


  • Console access
  • Serial Communication

Problems in using serial with other devices

If when trying to use the serial lines to communicate with other devices, the serial port generates errors about device not respond, not available and generally misbehaviours it is often as the serial lines are not under the sole control of the application being run, but still being controlled by the OS as part of console access. In order for reliable use the configuration of the serial lines needs to be configured.

Configuring the serial port

By default the RPi is configured to use the serial in a console mode in Raspbian and other distros for the RPi, the configuration  files that control the behaviour of the serial connections are the:-

/boot/cmdline.txt
/etc/inittab

These files need to me modified as follows. It is recommend that you copy the original files, prior to modifying them.

Modify the cmdline.txt file to remove reference to the ttyAMA0 device.

dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

And the inittab file needs to have references to the ttyAMA0 device commented out.

#Spawn a getty on Raspberry Pi serial line
#T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

Serial as a console connection

The initial configuration of the serial port allows it to be used for console access, allowing access to boot messages and providing a text based interface. Connection to the serial pins can be made with a TTL to USB cable such as the Adafruit cable. In addition to the cable if you are connecting to a PC you need your favourite terminal program such as Putty and it needs to connect to the serial port being used by the connection and configured to talk to the RPi. The Comm or serial port used by a TTL to USB cable can be found in Windows by examining the Device Manager screen.

RPi Default settings

Speed: 115200
Bits: 8
Parity: None
Stop Bits: 1
Flow Control: None


Programming the serial port

If the serial connection has been freed from the OS as described above, it can be used reliable within your own applications to interface with sensors and other devices.

The serial port is registered as a device using the name /dev/ttyAMA0 within the Raspbian distro, and similar names are used for other distros.

The port will often need to be configured and various opensource programme libraries are available for common programming languages that will help with configuring and programming the port.

From the command line the following can be used

stty -F /dev/ttyAMA0 9600

To configure the serial port and data can be sent or received easily using the following.

echo "hello, world" > /dev/ttyAMA0  # send a message
cat /dev/ttyAMA0                    # listen for a response

Hopefully the above has been useful, if you feel anything else needs to be added or explained, please drop me a comment.



Monday 14 April 2014

Heartbleed and a warning from history

The OpenSSL Heartbleed vulnerability has caused a lot of confusion by the press and by companies racing to release information and advice. Due to the nature of my job I have been asked by family, friends and acquaintances on what to do.

What you should NOT do, is use the tools that are on the web and test service providers for the vulnerability, doing so WITHOUT PERMISSION is illegal in the UK and other countries around the world.

Lesson from history


On the 6th Oct 2005 Daniel James Cuthbert was convicted of breaking Section 1 of the Computer Misuse Act of 1990 by hacking into a tsunami appeal website 2004 New Year's Eve. Cuthbert, told the Magistrates Court yesterday that he had made a donation on the site, but when he received no final thank-you or confirmation page he became concerned it may have been a phishing site, so he carried out two tests to check its security. This action set off an Intruder Detection System in a BT server room and the telco contacted the police. This lead to him being arrested, prosecuted and losing his job and having difficult to getting a job due to a criminal history.

Testing for Heartbleed without permission could lead to you being in the same position

What you should do


The sensible approach for an individual is to respond to your service provider, whether it is online banking or an ISP, advice. They will advice if they have been affected and not all where, and if they were affected there will advise on when they have patched their services and whether you need to change your passwords. If you use different passwords on different services only changes those have been requested to.

Be Aware of Phishing emails


Only respond to communication from your service provider, double check advice by going to their web page by typing the URL and not following links in the email.

For companies the advice is to check if you used the affected versions of OpenSSL and patch. Their are a lot of legitimate scanning tools and testing companies that can test for the vulnerability and confirm remediation. Afterwards you may need to get clients to change passwords and change your SSL certificates.



Thursday 10 April 2014

Preparing for and taking the CISSP exam.

The Certified Information Systems Security Professional (CISSP) examination from the (ISC)2 is consider by many to be one of the certifications an information security professional should have. Many of the employment positions for information security professionals list it as a required certification. However it is not an easy certification to gain; although a professional may have more in depth knowledge of a few of the domains, it is unlikely there have the required depth of knowledge across all 10 of the domains without studying.

I have been a CISSP for many years and into my third cycle of accreditation and I have been involved in getting other professionals ready to take the certification. The following is based on my experiences. Not all the tips may suit you but they could help and give you some ideas about preparing for and take the certification.

Taking the CISSP certification.


My first tip is to book the exam giving yourself a reasonable amount of time to prepare; not too short, or too long. I would say between 2 weeks and 2 months would be suitable, dependent on your existing knowledge and the amount of time you can give over to revising and preparing. It is not a certification to be taken lightly and you must set aside time to prepare, some domains of the common body of knowledge (CBK) you will be familiar with, but others you may have no experience of. Setting a realistic deadline gives you a target; if you wait until you think you are ready you may never take the exam.

I would obtain good study material, the official (ISC)2 guide to the CISSP CBK is a good starting point, along with downloading the current Candidate Information Bulletin (CIB) from the (ISC)2 website. There are other study guides available, if you go for these guides review the comments on sites such as Amazon where reviewers will leave their opinion of the material.

The CIB will give guidance and the current focus of the exam and it is often updated every few months. By looking at the overview and the key areas of knowledge for each domain you can determine focus areas to concentrate on. It also gives tips on the exam and advance knowledge of changes in format etc. In addition to reading the CIB and the guide to the CBK, I would recommend following all the suggested reading under the “more to know” section at the end of domain in the guide. The (ISC)2 recommend that you should have 5 years’ experience or about 10,000 hours to pass the exam, however being widely ‘read’ will help in understanding all the domains. My recommendation is to follow some of the many InfoSec blogs, you will soon realise which are the ones who are knowledgeable and should be followed. I would also recommend reading some of the good information security website and journals that are available. If you can tell the good ones apart from the bad, you are well on the way to becoming a CISSP.

So you have read the 10 domains in the guide, and the additional reading material, but did you understand what the guide was trying to get you to learn. My recommendation is to read up on terms you don’t understand and look at references to standards. Once you have completed your initial read of the material, you are ready to start preparing for the exam.


Preparing for the exam


The exam is 6 hours and 250 questions and not very cheap, it is a daunting task. I will be discus strategies for doing the exam a bit later. However, you have done the initial read through and a have reasonable amount of time before the exam day. My advice is to concentrate on your weaker domains, do the questions at the end of each of the domains in the guide, if you can correctly answer the questions, you understand the concepts, concentrate on the domains where you under performed.

It will become apparent the questions in the guide are not enough and you need more practice questions, to get you more comfortable with the wording and help identify where the gaps are in your knowledge of the CBK. I recommend the official (ISC)2 questions, you can purchase 3 sets of 100 questions from their studISCope web site, or get an app for the iPhone from the iStore or via link on their main website. In fact their guide is available in electronic format as well as in print. On their website there is a guide to study resources, I recommend you review these and decide if you need to use them. Some of the good 3rd party study guides that are available will have electronic practise question guides to help test your knowledge.

Repeating the test and concentrating on your weaker domains will build up your knowledge. The exam is marked out of 1000 and you need to obtain a score better than 700 (70%), the actual weighting of questions and the number of questions from each domain is not generally knowing, what is known that 25 questions are test ones and don’t count to your final pass/fail
I would say that if you search for study guides and cheat sheets on Google, you may find some and you may find lists of questions purporting to be actual exam questions, take these with a very large pinch of salt, there are very unlikely to be the exam questions and likely to contain mistakes that can mislead. The good exam guides and websites which are highly rated, will have questions to test you, however the most pertinent ones are those from the (ISC)2.

Some strategies to follow when preparing for the exam is to consider the exam environment, most people when recalling information do so when the environment we are recalling it in, is similar to the one we gained the information in. The exam environment is quiet, bit not nicely silent, so preparing in a quiet environment it will help. You will not have time for a lot of coffee or energy drinks etc. during the exam, so don’t go overboard on this during the studying. You are not going to do the exam in you pyjamas, so don’t revise in them, additional you are not going to sit in a formal suit either, pick comfortable clothes, and as physical stimuli can keep recall information it needs to be clothing similar to what you will wear in the exam.

Also we don’t often concentrate for 6 hours, whilst I’m not recommending doing 6 hour long revision sessions I will recommend revising for several hours at a time and building up you concentration skills.

The technique I recommend is doing a practice exam, identify you worst domain, re-read the domain, research the topics online and read around the subject. Retake the practices exam and repeat. Don’t forget to read widely about and research the topics. You should as you get nearer the exam date, score evenly across all the domains, but don’t panic if you have a blind spot for one of the domains.

So you have done the revision, you have done the practise questions you score highly in these; you are ready for the exam.


Taking the exam.


For the exam itself, there are some strategies that can help. The most important is to stay calm and manage your time. Once you start the exam you will have 360 mins to do the 250 questions, approximately 1.26mins per question. I am not saying this to panic you but to give you sense of how must manage your time, especially if you have to take a comfort break or two during the exam.
Out of the 250 questions, 25 are ‘research’ questions that don’t count; however you don’t know which ones there are as you take the exam. Every question should be answered as if it counts, don’t leave any unanswered questions. If you are running out of time, answer all the questions by guessing, at the best it could be your lucky day, you have not lost anything just by answering them.

My tip for the exam is to go through the questions and answer those you know immediately, if you have to think about a question move on to the next. Don’t get disheartened if you don’t know the answer for the first 25 questions off the top pf your head or you go through sequences of questions without knowing the answer. You can go back and answer the ones you skip, once you have done the first run through, hopefully you have done close to half the questions. What you will find is that you now have more time for the remaining questions as you likely answered the questions you know in under a minute per question. You can now do the remaining questions and you will have more time to do so.

For each question, read the question, read the answer, read the question and answers again before you answer it. It is very easy to assume you know the answer because you recognised keywords rather than understanding the question.

For each question there are four answers, you need to select the best answer, if you not sure which one is best, examine each answer in turn and eliminate the obviously wrong ones, at the best you will go from a 1 in 4 guess to a 1 in 2 guess. However I would recommend if you are having problems proceed to the next question and come back to the question later. Often a word in another question or answer to another question will trigger the memory that will enable you to answer a difficult question.

If you have time, you may want to review your answers, however bear in mind that often first instinct is the right one, only change an answer if you are confident you know the answer.

In terms of comfort breaks, don’t skip drinking water, you brain needs it, but don’t overdo it and end up spending precious time by making yourself more comfortable rather than answering the question.

Hopefully I have given you some tips and thought on how to prepare for the CISSP exam, gaining the certification can widen you knowledge of security issues and open doors in your career. Good luck

References

https://www.isc2.org/CISSP/Default.aspx
https://www.isc2.org/practice-tests-app/Default.aspx
https://www.expresscertifications.com/ISC2/Catalog.aspx

Saturday 5 April 2014

Testing RFID Reader on Pi

In order to ensure communication between the SainSmart RFID-RC522 module is occurring correctly with the Raspberry Pi, I have developed a short routine that reads the version information from the controller on the module.

initialization of the RP



Need to initialise the connection between the Raspberry Pi and the RFID module. The connection for which is shown in early blog rfid-and-raspberry-pi. This sets the speed of the SPI interface and configures the GPIO interface to allow a hardware reset to be sent to the module.

Code snippet
  def __init__(self,spd=1000000):
    spi.openSPI(speed=spd)
    GPIO.setmode(GPIO.BOARD)    # Set the mode of numbering the pins.
    GPIO.setup(self.NRSTPD, GPIO.OUT)    # GPIO pin 22 is the output (NRSTPD - Reset)
    GPIO.output(self.NRSTPD, 1) # Set GPIO pin 22 to high (set low to reset)

Reading the version setting


To access data on the module a read or write operation needs to be performed on the appropriate register, this requires sending the command via the spi.transfer command to the attached module.

For finding the version we need to read the register in the module that relates to the version. From the documentation for the NXP RC522 chip the register is known as VersionReg

  VersionReg      = 0x37 # shows the software version

The format of the command is given below.

msb = 1 for read / 0 for write 6 bits for register address lsb = 0

To correctly format the data to be sent for the NXP RC522, we need to do the following

  1. bit shift the register address left by one bit
  2. ensure the lsb is zero
  3. set the msb to 1 for a read / 0 for a write
This can be done by using the following

(((MIFAREReader.VersionReg<<1) & 0x7E ) | 0x80,0)

The read operation returns a two byte value, the first indicating a successful operation, the second indicates the version which can be decoded.

The complete code for this is shown below

Code snippet
readerVersion = spi.transfer((((MIFAREReader.VersionReg<<1) & 0x7E ) | 0x80,0))

if readerVersion[1] == 0x91:
print "Reader Version: MFRC522 1.0 software version"
if readerVersion[1] == 0x92:
print "Reader Version: MFRC522 2.0 software version"

To read the software version from the module we just need to put the code together. A screenshot of the resulting output is shown below.


Sourcecode


I am developing a SourceForge site to host code from this project. At the moment it is only in the very initial stages of setting the site up.

Download of the code described is available here

http://sourceforge.net/projects/rasprfid/files/ReaderV.py/download

Over the coming months I will be publishing more on hacking RFID using the Raspberry Pi.