lf em 4x05write with password - Query

[mwalker33]

Hi, this is more query then an issue (until I have completed more testing) Just started to look at the 4x05. I could read and write (no password protection/write protection). I set a password then set the write protect bit, such that a login is needed.
Once this was done, I could read, but no longer write (even with the password) Command Used : lf em 4x05write a 4 d 0001805F p feedbeef (should be enough to clear the write protect bit). I had a quick look at the source and a quick play. (for testing) I setup the code such that the SendForward funtion would only seed the following block of code once.

// Set up FPGA, 125kHz or 95 divisor
LFSetupFPGAForADC(95, true);

// force 1st mod pulse (start gap must be longer for 4305)
fwd_bit_sz--; //prepare next bit modulation
fwd_write_ptr++;
FpgaWriteConfWord(FPGA_MAJOR_MODE_OFF); // field off
WaitUS(55*8); //55 cycles off (8us each)for 4305  //another reader has 37 here...
FpgaWriteConfWord(FPGA_MAJOR_MODE_LF_ADC | FPGA_LF_ADC_READER_FIELD);//field on
WaitUS(18*8); //18 cycles on (8us each)

Once done, the command with the password seems to work worked as expected.

My query. Given that (from my understanding) that when using the password/login the chip needs to stay active. Could running the above code twice (once for login, then once for the write command) not be ideal ?

[marshmellow42]

Interesting point. I've never had trouble writing or reading em chips with password as is, so I left it in. The gap shouldn't be enough to discharge the chip (or it couldn't hear any cmd).

I'll have to check the datasheet again to see if it covers subsequent cmds.

What chip do you have?

[mwalker33]

It is meant to be a EM4305 (look and acts like one). It is a smaller fob, so correct position on the antenna is needed.

Note: This is not a request, more a discussion point.

I will need to repeat the tests a few time to confirm. Maybe its just not getting a strong induction and does decay a bit too fast. Just a thought. I will try to repeat a few times over the week and confirm, I might order in some cards as well for testing.

The detailed specs seem a little light on in my datasheet. This is about all I could find. "...When the Login command is successfully processed, the IC responds with preamble pattern (00001010) and returns to Default Read mode...." and "...Login flag is set until the next power-up, which means that Login command has to be sent only once after power up to enable execution of password protected commands...."

So I read that as, Energize Chip, Send Login, Read 00001010 (login ok) then proceed with any other command protected or not until the chip is disabled or "shuts down" (logon only needed once). My thought was that IF things are on the borderline of not working (antenna mismatch) then the less chance to drop in power the better.

For reference. This is on an PM3 Easy Measuring antenna characteristics, please wait......... LF antenna: 33.14 V @ 125.00 kHz LF antenna: 25.44 V @ 134.00 kHz LF optimal: 33.69 V @ 122.45 kHz HF antenna: 31.20 V @ 13.56 MHz Displaying LF tuning graph. Divisor 89 is 134khz, 95 is 125khz.

[marshmellow42]

I would guess you are correct, you're small chip is on the edge of coupling with you're antenna.

I had tried to lower the gap to 37*8 when I implemented as I snooped another reader doing that, but it didn't work consistently for me.
( granted I had a very strong coupling - big card, matched antenna)

Without the gap at all I'm surprised your chip recognized the command and came out of reg read mode.

[marshmellow42]

Wrong button .... stupid small phone screens..

[marshmellow42]

I'll try to do some testing, but I am out of town and won't be near my pm3s for a few weeks.

[mwalker33]

Very Low priority.
I have ordered some cards to play with as well.

[pwpiwi]

Does anyone of you use a RDV4? There might be differences as well. I didn't check the LF part yet, but the HF antenna continues to oscillate for quite some time even after the carrier is switched off.

[marshmellow42]

I have one and it did work, but barely as I recall. I kinda gave up on the rdv4 with lf...

Unfortunately I'm a few weeks away from it at the moment

[mwalker33]

On the RDV4 (rrg fork) it cant read the fob at all (or as good as). Given the LF antenna challenges (waiting to see if the new lf antenna will make it to market), and being a fob I was not expecting too much. To get a read at all on the rdv4, I had to remove to cover, place the fib right on the antenna and reflect the signal with a bit of foil underneath the unit. The Easy mostly works when you get the position right. My RDV4 has some t5577 challenges as well (as most I think), but the foil trick gets it working well in the field.

[mwalker33]

To be honest, I more then happy to put it down to coupling issue. After a lot of playing I can make it work with the original settings, just need to be more exact with a good position. Once its position is just right, it will work nearly every time (on current software), just seems a little bit easier with a tweak. I also tested have all the original code back in except LFSetupFPGAForADC(95, true); (on the command after the login), as that should already be done from the login. I will see how it goes with full size cards when they arrive.

[mwalker33]

Some test results. From the way I understand things, when using a password, you login to the chip and as long as the chip does not loose power, then the login will remain active. When sending a command you need to tell the chip to stop normal read mode by sending a field stop, then the command. So, that said, as long as there is only a single command at a time, then the code as is should be correct.

When sending the password write, then we need to make sure there is enough of a gap between the password/login and the write (to ensure the write is a new command (> 586 u sec (t_process_pause) + time for preamble (00001010 OK or 00000001 Fail). At the moment this is most likely taken care of by the time for the LFSetupFPGAForADC(95, true); as the read/write commands dont have any delay between login and read/write.

For testing I added the following to the end of the login function.
WaitUS(400); // Now do the acquisition DoPartialAcquisition(20, true, 6000, 1000); This allowed me NOT to complete the write and confirm the password was accepted by its preamble returning to the client. The login was OK in every test I did.

All that said, while there may be some fine tuning that MAY help a little, The bigger challenge is still antenna coupling and power (not a software issue). Some interesting tests results with my unit and my 4305 fob.

• Place the fob on the proxmark such that every read of block X works.
• Send a non-password write command and ensure it works (every time)
• Send a password protected write command (even though password not required) Finding : The more consecutive 1's in the password the less stable it is. In the above setup ( I expect it will vary between gear).

lf em 4x05write a 11 d ff000000 p 00000000 : Fails nearly every time lf em 4x05write a 11 d f0000000 p 00000000 : Works most of the time lf em 4x05write a 11 d 80000000 p 00000000 : Works every time (note randomin tesing of the position of the FF hints it can be anywhere (e.g. 00ff0000). Given that to send a '1' we are leaving power on and '0' dropping the field (as I understand it), the more consecutive '1's is a puzzle)

Edit: After some more thought and reading. I think i am close to the base of my fob challenge. Timings. Its meant to be 32 8 us (on) 1 and 32 8 us (off) 0 Then the datasheet talks abut the "off" not being off for the full 32. Then I noticed the total "off" ticks did not sum to 32 rather 23 + 18 = 41. So to test I adjusted that to 32-23 (for the 23 off) With that setting I am getting much better results. When the fob is placed on the proxmark, I can read and write with/without a password (as needed) inc. the protected write. In the past I would have to hold the fob in a special position to get password protected read/writes. (I will test on the full cards when the arrive).

while(fwd_bit_sz-- > 0) { //prepare next bit modulation
    if(((*fwd_write_ptr++) & 1) == 1)
        WaitUS(32*8); //32 cycles at 125Khz (8us each)
    else 
        //These timings work for 4469/4269/4305 (with the 55*8 above)
        FpgaWriteConfWord(FPGA_MAJOR_MODE_OFF); // field off
        WaitUS(23*8); //23 cycles off (8us each)
        FpgaWriteConfWord(FPGA_MAJOR_MODE_LF_ADC | FPGA_LF_ADC_READER_FIELD);//field on
        WaitUS((32-23)*8); //18 cycles on (8us each)

// WaitUS(18*8); //18 cycles on (8us each) } }

[pwpiwi]

Hmm, Shouldn't the WaitUS() be before the FpgaWriteConfWord() ? I.e. 23 cycles on and then 32-23 cycles off?

[mwalker33]

I don't know the history here and since there is a comment about other chips, I will need to read those tech sheets as well, as the code may be a balance (?). In theory I agree. the order seems a little out, but I think the whole bit stream is out of phase a little by timings in the initial stop/start '0' (sync). The 4305 should be Stop and sync '0' Then the packet bit stream. if '1' then leave "on" if '0' then turn "off" (for part of the packet) i.e leave it on for a bit and then off to allow less "off time"/more recharge time, as long as the off is in the correct position to be detected. i.e.the "on" time is needed to ensure a string of "0" does not drop the power.

I will test how i think it should be and report back. I don't have any of the other chips, but will see if I can get the data sheets and read and see if there is any difference.

[mwalker33]

After reading the datasheet for the 4469 and the 4305 a few times, this is were I am at. I believe the order is correct. The chip will monitor the first half of the 32 ticks (i.e. 16) if "ON" then 1 if "off" then 0. The 4469 data sheet says that the chip (itself) will turn off its modulator for the last 16 ticks of a "1" to charge up. The zero, in theory could be off for the whole time, but turning back on before the 32 ticks will help, even recommended. So apart from the above timing change to make it an even 32, I would look at the initial "off" The chips expect a "0" immediately after the Field off. So either make that the same 32 tick timings as the zero in the main loop, or remove that code and insert a 0 at the start of the stream. The other comment I noted was the 4469 says the "0" should be 16 stopped then 16 "on" (or even "on for 1-5 then stopped for the remainder of the first 16,, then on for the last 16 (this is to ensure the chip is has turned back on its modulation).

In my testing, I made the initial off/on the same as the "0" in the loop and tested on my 4305 fob. with the fob placed in the middle of the lf antenna I could read/write with/without a password and dump all blocks without any fails. So for my 4305 fob, it is a lot better.

I don't have the other chips mentioned so cant test those.

[pwpiwi]

This somehow contravenes with the 4305 datasheet:

The forward link communication protocol is identical to the EM4569/EM4469.

which would imply that it is the same as you described.

However

In order to achieve reliable communication also for higher Q factors, it is proposed to send a logic "0" by keeping the reader field ON for 18 RF periods and switching it OFF for 14 RF periods. Increasing the field stops up to 23 RF periods improves communication robustness.

which seems to be quite the opposite. Confusing.

[mwalker33]

I agree confusing, i keep re-reading.

from my 4469 data sheet. "...To send a logic "0" bit, the transceiver stops sending clocks (100% modulation) during the first half of a bit period (first 16 periods with modulation device ON)...."

from my 4305 "...When sending a logic "0", the reader field shall be stopped while the chip is in MOD_ON state...."

In this case I noted the "chip" is in Mod_On state and "device". Also "...during the first half..."

I ran a test putting the wait above the fpga calls, no other changes. Then a 2nd test with the wait still above the fpga calls but with the wait times set to 18 then 24. Order as is current code - worked very well.
Wait above the fpga call failed every call.

The way I am looking at it is. IF the chip turns off "its" modulation at 16 ticks of a "1" to recharge and we leave it on for > 16 ticks for a 0, it will never see the "off" to see the 0.

I think what is meant to happen is the "reader" monitors the chip modulation state and should not turn the field off until the chip is in a mod-on state (keeping it in sync). I believe the initial wait is intended to ensure the chip is "fully on" thus will detect the off from the reader (i read 1-4 ticks i.e. just past the chips on edge).

I had a look at the wave forms by sending from my easy and sniffing with the rdv4. Code as is has a clock cycle when 0 (one period) and flat line (or decay) when 1. which seems to match the datasheet.

[pwpiwi]

What happens if you put it this way for a logic 0:

• wait 32-23
• field off
• wait 23
• field on (This is how I read the 4305 datasheet)

[mwalker33]

Yes that, was one of the tests i did and I could not read or write (at all).
Believe me, I am with you 100% on the way it reads and how the code looks, but given the test results (and history of that code being there), I concluding my understanding and the terms used don't line up.

I think my miss understanding is around the rf field being on (to energize the chip) and the modulation field being on, to "signal" the chip.

[mwalker33]

this seems to gel with the current code https://www.emmicroelectronic.com/sites/default/files/products/datasheets/an604010.pdf

Skimming over the terms used (high/low) the 0 is the inverse of the 1 for 15 RF Cycles. then the same as the 1 for the reaming 17 RF Cycles. (as the current code is) Also looking at the wave forms from the lf snoop/sniff, I would call the 0 "high" and 1 "low" (I am starting the thing the 4305 datasheet is just backwards. as it says the opposite of every of document.)

For transmitting logic bit ‘0’, ‘1’;

1. For logic ‘0’; a. Set mod pin of EM4095 to ‘high’ for 15 RF cycles b. Then set mod pin of EM4095 to ‘low’ for 17 RF cycles
2. For logic ‘1’ – set mod pin of EM4095 to ‘low’ for 32RF cycles.

[pwpiwi]

At least this seems to be common for the data sheets: at the reader side, a "1" means "modulating", which means " field off".

[mwalker33]

mmm Trying to get my head around this. 4469 : To send a logic "1" bit, the transceiver continues to send clocks without modulation wont the field need to be ON to send the clocks ? 4305 : For sending a logic "1", the reader field shall stay ON for 32 RF periods. This directly says field shall stay ON for a "1" The chip turns "its" modulation off half way through a 1 in order to charge. So that all seems to say the field is ON for a 1

Then for a 0 4469 : To send a logic "0" bit, the transceiver stops sending clocks (100% modulation) 4305: When sending a logic "0", the reader field shall be stopped

so to me that seems to line up. i.e. "1" Field ON - No modulation The bit a find contradicts is. 4469: To send a logic "0" bit, the transceiver stops sending clocks (100% modulation) during the first half of a bit period (which i tend to agree with) 4305 : proposed to send a logic "0" by keeping the reader field ON for 18 RF periods and switching it OFF for 14 RF periods (which does not seem to match with whats working)

i.e. the 4305 seems to be the reverse order of the 4469 when it comes to the "proposed" option. to me the reader datasheet lines up with the 4469 statement.

The way i read it all is the reader datasheet, the 4469 data sheet and the existing code all line up. The 4305 datasheet seems mostly right except the "0" on/off order.

[pwpiwi]

Yes. I fully agree. Seems to be an error in the 4305 datasheet.

[marshmellow42]

glad i'm not the only one that was confused by their datasheets.. i compared at least 4 different ones a while ago when i tweaked this code. the timings that exist today may or may not be optimal. if you find something that works better for you i'd be happy to test it next week.

one thing i know we are not doing, is following the datasheet recommendations when it comes to syncing to the tag's modulation. i'm not sure we can, or need to, as it seemed pretty reliable as it is with a good hand made antenna and a card sized tag.

[mwalker33]

From my testing with my fob (only have the one type atm) with one change I got much better results. i.e. just placed the fob on the easy (center of lf antenna) and all commands worked 1st time every time. prior the fob read ok, but most writes had issues and needed to hold the fob on an angle in the right spot.

while(fwd_bit_sz-- > 0) { //prepare next bit modulation if(((fwd_write_ptr++) & 1) == 1) WaitUS(328); //32 cycles at 125Khz (8us each) else //These timings work for 4469/4269/4305 (with the 558 above) FpgaWriteConfWord(FPGA_MAJOR_MODE_OFF); // field off WaitUS(238); //23 cycles off (8us each) FpgaWriteConfWord(FPGA_MAJOR_MODE_LF_ADC | FPGA_LF_ADC_READER_FIELD);//field on WaitUS((32-23)*8); //18 cycles on (8us each)

from the above code snip, the very last line (coded for clarity) was the only change. i.e. The 2nd wait in the else was changed such that the sum of the "0" waits is 32 * 8.

[marshmellow42]

That makes sense as to how I read the ds as well. I'll test that with my setup and make sure there's no surprises, then we can patch that change

[pwpiwi]

one thing i know we are not doing, is following the datasheet recommendations when it comes to syncing to the tag's modulation. i'm not sure we can, or need to, as it seemed pretty reliable as it is with a good hand made antenna and a card sized tag.

I understand that syncing can be compensated by having the first gap very long (some datasheets recommend 100 cycles - but I am wondering if this wouldn't power down the card completely if coupling isn't good).

[marshmellow42]

i find no difference on the different tag types with my setup with the corrected timings, so i propose we adjust the timings to match our current understanding of the datasheets. (32 * 8us per bit)

i have made a PR #846

[mwalker33]

I have synced and tested, all working as expected. Thanks.