hey@hedger ,@DrZlo13 ,@nminaylov ,@skotopes ,
any action required from my side?
forgive my ignorance, this is my first contribution to an open source project

Scheduled on next release

Waiting for hardware to verity, moving to next release

Sorry for delay. This PR requires some extra spaces that we planning to free in 0.87 release.

not sure if I understand what you mean with extra spaces (extra memory space?)

but no worries, just let me know when you plan to pick this up, since I've seen that meanwhile furi_hal_rfid has undergone some changes with the FuriHal bus abstraction. and I might need to rewrite some code to make it compatible again

no point in continuously keeping it updated with all intermediate commits, I'd rather do a final update when it's relevant...

I'll post update as soon as we free enough space

We are ready to merge this PR, please merge dev and update to match new API. There were couple changes that may require change in furi_hal_rfid, please ping@DrZlo13 to get more details

alright, on it.
reviewing the furi_hal_rfid changes, though I suspect there's some thread handling changes as well I might need to catch up with
any advice on where to search for this/whom to contact?

@blackvault88 feel free to ping@DrZlo13

thx, though not needed anymore, seems as if the thread updates which I was referring to (#2637 ) have no impact on my coding

meanwhile I updated my code to comply with the bus abstraction (#2614 ). it builds and runs nicely on my FD.
reading is working as it should
emulation is running without errors, though haven't had the time yet to test it with a reader, hope to do that over the weekend...

if successful, I'll recommit the updates

@skotopes ,@DrZlo13

tested and recommitted, ready for your review/approval

fyi, there seems to be some other changes in the firmware that have a negative on the successrate of the hitag emulation mode.
when built on the dev branch at time of my first developments (May 10th) the hitag emulation yielded results in +/2-5 seconds
when built on current dev branch the same coding for emulation only yields results somewhere after 10-30s (meaning that the reader which I'm testing with needs quite a few tries to successfully read the pages consecutively without issues).

note: to check if it is related to my coding updates or to other changes in the firmware, I also rewrote and built the code to match the dev branch at time of that first deep sleep mode release and that also has the same negative impact.
not 100% sure if it is related to that deep sleep setup, since also running in legacy seems to have the same 10-30s success rate, but it does make me quite sure that there's some 'external' impact on how my code gets executed which impacts the emulation mode.

I would welcome a critical eye that might know what could impact the coding in my emulation routines
for now, it's a working version with 100% successrate on the reading, and some successrate on the emulation

• I have bunch of tags: one of them is forever reading(really small one, cable marking type), 2 otherpages read: 50/64. Do your tags behave same?

50/64 is expected behavior: there's a minimum of 14 non-public (encrypted) pages on a HITAG 1 tag.
current functionality is reading the public (non encrypted) pages only, which could be anything between 34 & 50 pages.

About the one that is reading forever, are you sure it's a HITAG 1 and not a HITAG 2 or HITAG u or HITAG S?
Does it detect an ID and then get's stuck reading the pages, or does it not detect anything at all?
can you check the debug log while reading?
it should give out something like this:

6373214 [D][LFRFIDWorker] Start ASK6373219 [D][DolphinState] icounter 1017, butthurt 06373677 [D][LFRFIDWorker] Read started6376986 [D][LFRFIDWorker] Read stopped6377041 [D][LFRFIDWorker] Start PSK6377503 [D][LFRFIDWorker] Read started6379522 [D][LFRFIDWorker] Read stopped6379576 [D][LFRFIDWorker] Start RTF6379579 [D][DolphinState] icounter 1018, butthurt 06379587 [D][LFRFIDWorker] Read started6380900 [D][LFRFIDHitagWorker] Hitag1, [34 80 68 A5] found6380902 [D][DolphinState] icounter 1021, butthurt 06381562 [D][LFRFIDHitagWorker] Hitag1, [34 80 68 A5] config page read6381565 [D][LFRFIDHitagWorker] Hitag1, [34 80 68 A5] block 1 not public/readible6381567 [D][LFRFIDHitagWorker] Hitag1, [34 80 68 A5] block 2 not public/readible6381570 [D][LFRFIDHitagWorker] Hitag1, [34 80 68 A5] block 3 not public/readible6382048 [D][LFRFIDHitagWorker] Hitag1, [34 80 68 A5] block 4 read6382507 [D][LFRFIDHitagWorker] Hitag1, [34 80 68 A5] block 5 read6382917 [D][LFRFIDHitagWorker] Hitag1, [34 80 68 A5] block 6 read6383327 [D][LFRFIDHitagWorker] Hitag1, [34 80 68 A5] block 7 read6383721 [D][LFRFIDHitagWorker] Hitag1, [34 80 68 A5] block 8 read6384164 [D][LFRFIDHitagWorker] Hitag1, [34 80 68 A5] block 9 read6384574 [D][LFRFIDHitagWorker] Hitag1, [34 80 68 A5] block 10 read6384968 [D][LFRFIDHitagWorker] Hitag1, [34 80 68 A5] block 11 read6385378 [D][LFRFIDHitagWorker] Hitag1, [34 80 68 A5] block 12 read6385805 [D][LFRFIDHitagWorker] Hitag1, [34 80 68 A5] block 13 read6386199 [D][LFRFIDHitagWorker] Hitag1, [34 80 68 A5] block 14 read6386624 [D][LFRFIDHitagWorker] Hitag1, [34 80 68 A5] block 15 read6386671 [D][LFRFIDWorker] Read stopped

• How emulation should be tested? Reading with another flipper barely detects it.

I've tested it using a real reader, though am also experiencing issues with readers taking up to 30s (sometimes a minute) prior to succesfully reading it since after the FZ firmware updates of May June (cf my post#2658 (comment) )
Though I have no idea what caused the sudden fallback in emulation results :(

Some PVS warnings that need to be addressed

As for emulation issues: difficult to say what exactly happened in June. There were some major changes in July, but not in June. If you can specify working commit in this branch then I can try to fix it.

Couple more things that prevents us from merging this PR:

• TODO: we are currently cleaning up firmware by fixing all of them, please try to close as many as possible.
• Worker source code: requires refactoring. Not like 2k lines of code are frightening us, but we clearly we'll be unable to maintain it in its current form. I see there multiple layers mixed it will be nice if they will be split into separate files.

Ok, will look into the PVS warnings & my TODO notes

If you can specify working commit in this branch then I can try to fix it.

for the emulation results, I'll see if I can trace back in time to find latest version where emulation was yielding faster results

• Worker source code: requires refactoring. Not like 2k lines of code are frightening us, but we clearly we'll be unable to maintain it in its current form. I see there multiple layers mixed it will be nice if they will be split into separate files.

I can easily split up the functional blocks into separate files, though one of the blocks would likely be positioned better into furi_hal_rfid, though that would also increase file size there... Any advice on what would be acceptable?

I can easily split up the functional blocks into separate files, though one of the blocks would likely be positioned better into furi_hal_rfid, though that would also increase file size there... Any advice on what would be acceptable?

Yes, everything related to low level should be in furi_hal_rfid, also it will speedup this code. Also@DrZlo13 may have some ideas.

worker source code refactored and moved all low level code towards furi_hal_rfid

ready for your review and approval to merge@skotopes

and some good news on emulation mode:
emulation mode is back to normal result times (eg reader manages to read the full emulated tag in +/- 5s)

not sure if this is due to moving low level code to furi_rfid_hal or due to other changes elsewhere in firmware, but it's a nice extra :)

I'll take a look after we release 0.94

hey@skotopes , how's the review going?

any input/changes required?

@blackvault88 yes, are you on discord? can we chat a little bit?

@blackvault88 yes, are you on discord? can we chat a little bit?

nope, not active there, any alternative? eg the FZ forum?
if not, i can always create a discord account... let me know

hi error after write to original card please help me 100 euros gift for succes hack

need write my need to original card (

@blackvault88 appreciate your work on Hitag! Is there any plan to continue work on this PR?

@blackvault88 appreciate your work on Hitag! Is there any plan to continue work on this PR?

hey@drussilla ,

it mainly depends on the FZ team. the source code was complete & working (as tested on local hardware). I had also restructured the coding as requested, but somehow it was never picked up.

I must say though that currently I do not have the time to further restructure the coding to get it in line with any other firmware updates done since December last year...

I just flashed this to my flipper and received an error telling me to update the firmware due to the API version being too new.

Thanks for making this@blackvault88, I was excited to try it out. Sucks I wasn't able to check out the working version.

Thehitag branch (from@blackvault88) I am working on is relatively up-to-date with the flipperzero-firmware repository. However, it is based on the unleashed firmware. I was unable to fully test it because my test tag does not appear to be a Hitag1. That said, I was able to run the LFRFID app in RTF (Hitag1) mode.

My branch:semrekkers/fz-unleashed-firmware:hitag

We are ready to accept hitag if it will be in "Extra Actions" menu. Other than that requirements are the same: clear separation in HAL/worker.