Research, development and trades concerning the powerful Proxmark3 device.
Remember; sharing is caring. Bring something back to the community.
"Learn the tools of the trade the hard way." +Fravia
You are not logged in.
Time changes and with it the technology
Proxmark3 @ discord
Users of this forum, please be aware that information stored on this site is not private.
i would expect the highest value for the digit after FFFF would be 7 so highest possible number = 7999999999 otherwise it would be difficult to determine the preamble (start of stream) so preamble is likely something like
11111111111111110
? but might be necessary to test to be sure.
could try:
FFFF9999999999C7
FFFF8999999999D7
FFFF7999999999E7
FFFF000029447FD6 what would this output?
to answer the few remaining questions regarding this format.
Last edited by marshmellow (2016-07-29 16:18:02)
Offline
yup, I added that the MSB the digit after FFFF is not set in clone/sim,
and for the preamble detection it looks for 17bits, to get the zero bit also.
But OP should test it out against his valid reader, as I've asked him to do.
Offline
great work on the jablotron fork update! I am testing it and will post my findings in the other post.
test results:
FFFF9999999999C7 --> no reaction
FFFF8999999999D7 --> no reaction
FFFF7999999999E7 --> 370-5032-703 (strange result from reader)
FFFF000029447FD6 --> 14100000294485
Offline
The higher
----+-------------ch
FFFFA000011001
The 'A' hex symbol is interesting to try 0-F, against your reader. The output will tell us more about the preamble.
Offline
so 11111111111111110 preamble is confirmed.
not sure why 7999999999 produced 370-5032-703.... odd
and 29447F resulting in 294485 is odd as well. it converted the F to decimal and added it to the rest of the number in decimal...? probably just not expected by the reader so it is an exception...?
Offline
The higher
----+-------------ch
FFFFA000011001The 'A' hex symbol is interesting to try 0-F, against your reader. The output will tell us more about the preamble.
9 and 8 will have the highest bit set, 7 sets all the other bits - and 7 worked (ish). i doubt higher will work but as long as testing is fun...
Last edited by marshmellow (2016-07-29 18:47:48)
Offline
Yep, agree about preample.
The hex only allows values between 0-9 and not A-F, there might be BCD involved
'7999999999' - 70-5032-703, is strange indeed
Offline
The hex only allows values between 0-9 and not A-F, there might be BCD involved
that is what i was attempting to test but i expected a failure or error or something else, not 85 from 7F
meaning it did 70+15 (F) = 85 - odd.
it does mean that there might be more than one way to get 60% (0-5) of the possible numbers output from the reader...
294485 == 29447F. (not that it matters much... )
Last edited by marshmellow (2016-07-29 19:00:39)
Offline
You guys are fast in replying. just finished the other post.
testing is fun.......yep depends on the situation
So far ....a nice party against testing jablotron........ the party can wait a few more moments.
what to test?
I still test with lf simask.
Offline
If it is 70 + 15 then 0x7E == 84?
Offline
If it is 70 + 15 then 0x7E == 84?
correct
this is further proven by:
lf sim jab 18CFE = 19364
so:
E=14 == 4
F=15 +1 == 64
C=12 +1 == 364
18 +1 == 19364
Last edited by marshmellow (2016-07-29 19:57:05)
Offline
good thinking!
Offline
what i can't figure is WHY...
Offline
So, it takes hex, converts it to decimal and then adds it to gether when digit is > 9..
Offline
So, it takes hex, converts it to decimal and then adds it to gether when digit is > 9..
that is what it is doing... kinda...
it must convert each digit from hex to decimal and then multiply by digit (10s 100s 1000s etc.) then add it all up.
instead of doing it byte by byte it does it per 4 bits.
for 18CFE
1 = 1 * 10000 = 10000
8 = 8 * 1000 = 8000
C = 12 * 100 = 1200
F = 15 * 10 = 150
E = 14 * 1 = 14
10000 + 8000 + 1200 + 150 + 14 = 19364
this process must be what is used to convert the hex to decimal. odd.
Last edited by marshmellow (2016-07-29 20:40:54)
Offline
Its checking if the hex is not a BCD, for each nibble ie hex symbol. Look like its a custom built BDC implementation
And shouldn't it become: 19364 (above shows 19464)
the C should be 12?
Offline
correct
Offline
So I pushed some changes, if now prints the card id as @OP's reader output but the odd 7999999999 behavior I can't reproduce.
Offline