You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 24, 2021. It is now read-only.
The output shows the truncated 8b, 16b numbers used. However the check for Guardall seems to use much more bits than the clone command. Until the command "lf guard clone" is fixed to accommodate 32, 36 and 40bit types, Proxmark user should use "lf search" to get raw data then use t55xx write to create the Guardall 30-, 32- or 40bit
The text was updated successfully, but these errors were encountered:
The title is missleading. The functionality for lf guard clone has support for wiegand 26/32/36/40 and all other format length entered becomes 26 format. These different formats is not properly tested against a valid reader. GetGuardBits() function as commented in the source code currently work for wiegand26. I suppose this is the bug you want to report.
If you have correct conversions for 32/36/40 guardall wiegand format, do please contribute them.
otherwise the quick fix would be to limit format length input to the clone command.
Guardall's FCC is 8bits (or 256 max). for card number can only be 16bits (or 65535 max) as shown in https://github.com/iceman1001/proxmark3/blob/master/client/cmdlfguard.c#L165
The output shows the truncated 8b, 16b numbers used. However the check for Guardall seems to use much more bits than the clone command. Until the command "lf guard clone" is fixed to accommodate 32, 36 and 40bit types, Proxmark user should use "lf search" to get raw data then use t55xx write to create the Guardall 30-, 32- or 40bit
The text was updated successfully, but these errors were encountered: