Ok well I guess the fc and cn aren’t going to be easy to get… but you were able to make a working copy using the raw demod method?
Yes,
Well worth a shot.
Thank you amal and others for helping.
1 Like
I’ve tried to also copy this fob using lf pyramid clone --fc --cn but got stuck at one of the steps below.
I’ve managed to presumably get the --fc (facility code) and --cn (card number) values by assuming some variables, and supposedly cloned it to a T5577, but unfortunately, the cloned t5577 did not work… I believe it did not work because EITHER the fob is NOT a pyramid or T5577, and is some proprietary fob; OR I used the wrong variables (assumed it is a X-bit frame, see further below).
Here are the steps I took (with assistance of AI) for anyone else who would like to give this a crack.
NOTE: the below method assumes the fob is a Farpointe Pyramid. However, depending on region you are located, your fob may be a T5577 in which using lf t5 dump and lf t5 restore method is much easier and quicker. If your card is not detected as a T5577 (using lf t5 det), then you’re only option is to use the data rawdemod --fs method described previously.
Converting data rawdemod output into --fc and --cn
Step 1. Confirming repeating frame structure
Data rawdemod output states its a 16-byte repeating block of 8 bits (16x8 = 128 bits), divided into 4 lines (blocks) (32 bits in each block). This is why we can just take first 4 blocks when analyzing the data.
6398 samples / 8 bits / 50 clock
16 bytes repeating
4 blocks
01000011111111111111110000000101
11111101111111010000000000001001
11110111110110000000000011000101
00110111110001111010110000000011
Step 2. Identifying preamble (synchronization sequence)
The start of frame contains a long, stable sequence of 8 bits (pre-amble) used for framing and reader synchronization (which we can ignore):
01000011
Separating the frame visually gives:
raw[0:8] initial frame/preamble byte
raw[8:128] 15 parity-protected bytes
Preamble:
01000011
Encoded data following preamble:
111111111111110000000101111111011111110100000000000010011111011111011000000000001100010100110111110001111010110000000011
Each eight-bit group must contain odd parity. In every group:
dddddddp
ddddddd= 7protocol data bitsp= odd-parity bit
Then, we need verify that each complete eight-bit group contains an odd number of 1s, then discard its 8th bit.
BELOW IS WHERE IT OUTPUTS ARE INCONSISTENT AND NOT VALID
Step 3: Normalizing encoded data
The 128-bit frame is a transmitted protocol frame, not necessarily a direct Wiegand credential used in Pyramid. So the signal must be reduced/normalized to its underlying logical credential bits using detected FSK clock, symbol boundaries, and Pyramid encoding rules.
The data rawdemod output states:
FSK clock detected
FSK2 decoded bitstream
50 clock
16 bytes repeating
Normalization should therefore be based on the detected symbol timing and protocol structure.
facility_code = binary_to_decimal(wiegand[1:18])
card_number = binary_to_decimal(wiegand[18:38])
Run-lengths can assist with identifying timing, but protocol-aware symbol decoding should determine the final bitstream.
The proposed decoded credential is a 39-bit frame (here I assumed it is a 39-bit frame per random readings online, but it could be a different length…):
1 | 00011111000100 | 10011000110110111000000 | 1
This includes:
1 leading parity bit
14 facility-code bits
23 card-number bits
1 trailing parity bit
--------------------------------
39 bits total
Step 4: Applying assumed 39-bit field frame
Under proposed Pyramid 39-bit mapping, the fields are interpreted as:
Leading parity:
1
Facility code:
00011111000100
Card number:
10011000110110111000000
Trailing parity:
1
Because Pyramid credentials can use different programmed formats, this field division should be treated as an assumed format until confirmed by parity, system records, or a known test credential.
Step 5: Convert facility code --fc and card number --cn from binary to decimal
The 14-bit facility-code field converted from binary to decimal is:
00011111000100 -- > 00011111000100₂ = 1988₁₀
Therefore:
--fc 1988
The 23-bit card-number converted from binary to decimal is:
10011000110110111000000 --> 10011000110110111000000₂ = 5008832₁₀
Therefore:
--cn 5008832