kivijakola / hitager

hitager

The hitager open source project provides a GUI based Windows application for writing and reading 125kHz automotive RFID key transponders commonly used in car keys. It uses an Arduino (software also provided in this project) as interface between a PCF7991 base station IC (ABIC) and a Windows PC running the AESHitager GUI. Additional infos can be found at the homepage of the project initiator's website.

Main Features:

• Supported Protocols:
  • Hitag2, Hitag2+EE, Hitag2 Extended, Hitag2 BMW EE Extention
  • Hitag3
  • Hitag AES
  • Hitag Pro
• Special Devices:
  • VVDI Super Chip
  • BMW Key (e.g. PCF7944, PCF7945, PCF7953)

Hardware:

Hardware Architecture:

AESHitager PC <-------> Arduino <-------> PCF7991 IC <- - - - -> Key Transponder

Required Hardware

1. Arduino Nano / Arduino Mega2560
2. Board with PCF7991 Advanced Base Station IC (ABIC) (e.g. IPROG RFID Adapter, Key reader from Car, Hitag2 v3.1, ZedBull Mini)

Build your own Hitager

Detailed information on how to build the required hardware can be found in the project's Wiki

hitager's Issues

Add Hitag 3 write in cypher mode

Add Hitag 3 write in cypher mode

Hex editor doesn't display when built from source

Tried building with Visual Studio 2019/2022 and both give the same result:

Are there any specific build instructions/pre-reqs?

Also noted there is no app.manifest included, so visual studio adds one by default. The default sets dpiAware to true, but then the app doesn't draw properly on 4k screens when running with a scale of 125%. Would benefit from adding an app.manifest with dpiAware false (or better yet make it dpi aware). This doesn't fix the hex editor issue.

Explore and Implement writing of BMW CAS3 remote data - Producing BMW CAS3 remote

During analysis of Hitag2 V3.1 tool, it was found out that crypto data for remote is stored in block 15, which is read protected for 5WK49125 (for older 5WK49121 possible to read out by using special, already implemented procedure).

However, it is not possible to write block 15 by using normal BMW EE write command. It seems that for writing remote data in block 15, special procedure is required.

For producing a key with working remote, "write remote data" procedure has to be explored. We need a capture of this procedure from an available tool. Then we can implement that also for Hitager.

If anyone has the possibility to capture the ABIC communication during remote generation, please post it here. I can analyze and implement it.

Update Doku about connection Automotiv readers.

I do a lot of work to connect Renault card readers to hitager. I get lot of read errors, the fix is to connect Mode PIN 5 from PCF7991AT to ground to switch of the SPI filtering that limits the data rate there. Sometimes you just move a 0 Ohm resistors, other readers require som trace cut an rewiring. After that, is working fine.

Using Renault S118539001E card reader

Author uses card reader from a Megane III 2008–2016 with code 285909828R (A2C53185186), but I've found the a bit older device from Megane II, S118539001E. It still uses PCF7991AT but the circuit is sightly different.

The connection is standard, just desoldered lines from 12v conversion circuit of pins DIN, DOUT and SCLK and connected to Nano as follows.

PCF7991 Pin Name	PCF7991 Pin Nr.	Arduino Nano Pin
DOUT	10	D2
DIN	9	D7
CLK	8	D6
VSS	1	GND
VDD	3	VCC / +5V

Using the latest firmware and AESHitager app I was able to connect the device – all four buttons are getting green.
However, no reading from a real key is happening.. the post commands returns NORESP

My concerns is on circuit part:
PIN 10 DOUT was pulled up with 10K but I've removed it.
PIN 5 MODE is not connected to GND
Overall the RC connection is slightly different then on Iprog PCB schematic

Can you please suggest how to made a self test?

Using Renault 285916556R transponder ring as a reader

Hi,

First iof all congratulations for your huge work with Hitag. Carhacking is a very very obscure world where learning anything is a huge step.

I'm trying to use a 285916556R antenna coil for reading a Dacia keyfob with chip 2244706. I have been able to see some communications by modifying the firmware hitaguino to use a common din+dout (see https://github.com/josefe17/hitager/tree/common_dout_din) and adding I2C-type level shifters to interface the coil unit (their logic levels are shifted to 12 V) but i don't know if I'm doing well and getting valid things. In fact, I do communicate with the unit and the keyfob as displayed data changes when the key is not near but I don't get nothing similar to yours (plenty of FF, not good i think) and only Arduino and Receiver indicators are green, RFID adapter and transponder are red. I suppose chip is PCF7961M but I don't know how to check it. Would you mind helping me a bit undestanding what I am doing? My goal is being able to repair a key from a junk vehicle with another junk BCM from a different vehicle, and overall learning about this.

Regards and thanks a lot in advance.

Jose F.

Please add Hitag S Support

Ther a lot of application for Hitag S Tansponders, where I do some work. None of the commercial availble Programmer support them with crypto mode.
https://www.nxp.com/docs/en/data-sheet/HTSICH56_48_SDS.pdf
http://www.proxmark.org/files/Documents/125%20kHz%20-%20Hitag/HitagS.V11.pdf

Protocol is very simelar to Hitag 2

Investigate and Improve communication stability for BMW CAS3 (chip marking 26A0700) China Key

Problem:
On chinese CAS3 keys (IDE shows PCF7945 signature, transponder chip marking 26A0700, picture below), communication is very unstable. For example reading Block 2 takes various tries for reading the whole VIN correctly. Often there are wrong bytes or even complete wrong pages in between. Same phenomena I observed already when reading key's ID. I have also a second, identical key, which shows same behavior.
With original keys my reader HW works just fine.

Key:

Observations:

• The reading result strongly depends on the positioning of the key in the reader coil
• Seems that the quality of the key's HW layout is very poor

Necessary actions:

Although it seems not too imprortant to support this particular poor quality chinese key, it could be worth to analyze the reason for the wrong readings. Knowing the reson, we could maybe introduce measures (e.g. change ABIC configuration) that improves the robustness of the RF communication. This might be a benefit for other keys as well.

Next step:

• Capture data received from the key and analyze the signal quality
• Everybody who uses same key with Hitager, pls. post your experience here

Add support to "Set type of VVDI wireless remote"

In the current version it is supported setting the type of the SuperChip transponder (e.g. ID7946 type). Setting the type of the transponder does not set the type of the wireless remote.

Without this feature, when it is programmed a SuperChip remote (e.g. XEMQB1EN), the transponder works but the remote not. Indeed, in the Xhorse app, there is a "Special function" called "Set type of VVDI wireless remote" that supports such functionality.

Nissan leaf 2018

Is it possible to copy a 2018 Nissan leaf immobiliser key with this tool?

Hitager reading very unreliable

I observed that sometimes reading of data is very unreliable. For example when reading BMW 5WK49125 memory blocks, I have suddenly a reading error in one of the 4byte page (see following example):

Below are the captured pulse length for the faulty page:

Sending: i0aC1C0
transfer
ISRcnt:3F
42, 25, 40, 25, 40, 29, 32, 47, 18, 37, 36, 59, 36, 29, 30, 43, 62, 63, 30, 41, 60, 31, 38, 67, 64, 67, 64, 67, 60, 33, 32, 35, 32, 33, 38, 61, 30, 39, 60, 31, 38, 65, 62, 31, 32, 33, 34, 31, 40, 65, 60, 31, 32, 33, 32, 33, 40, 1911, 122, 139, 340, 39,
XXXXXXXXXXXXXXXXX
RESP:NORESP

Problem:
The pulse times representing a "short"-pulse show a hughe variation. Some pulse times of a short pulse are so long that they are considered as long pulse by Hitaguino's manchester decoder. Looking at the example above, decreasing the length of the 8th pulse from 47 to 45 would result in a correct decoding of the sequence (which is 0x89ABCDEF).

Possible Solution:

1. Improve reader's signal quality, e.g. by finding a better setting for the PCF7991 ABIC
2. Improve robustness of the manchester decoder. E.g. introduce a continuous pulse length adaptation, which continuously adapts detection threshold of a long pulse