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.
poor little clickbutton on the pm3....
one way is to write a lua script to test all 255 possibilities for 1 second each and print out the data the other option is to use reveng.(that sounds much better)
So this means next new lessons for me.
and yes I have tried about 25 possibilities for fun, no luck for me tonight so I am certainly not going to the casino.
Offline
that would a be very simple script to write, I imagine the reason marshmellow suggest doing the 256 bytes is that your test seems break our crc assumptions.
Reveng just calcs a CRC over bytes.
You need to keep the bytes fixed and only change the 256 possibilities as checksum, to find the correct one.
then you change the fixed bytes, and find which crc bytes it should be.
this way we collect data about the crc,
that data is what we gonna use in reveng once more
00112233[nn] where n is 0-255
00112244[nn] where n is 0-255
00112255[nn] where n is 0-255
Offline
To me the crc assumptions you discovered sounded like a real possibility because it worked in both real cards. (to me that couldn't be a good luck situation,right, it was cleverly calculated). So yes, a 1-0 for the manufacturer of the card/reader. So could it be that the assumption is correct (I still believe that) but that the reader itself has some other calculations/filters so it drops certain combinations or ranges.
I have asked for more of such cards so we can have more data if necessary (takes a little while)but it would be nice to clarify it with just 2 cards.
Offline
With the number of proceeding zeros I'd expect the system can take much larger numbers. I think the CRC guess is wrong. Meaning we need more valid samples. Simulated samples or real will be fine as long as the reader reads it.
Offline
i suppose you could try FFFF0000113948b5 (one number less than your other card#.)
Offline
From Marshmellows Post# 32 "
suggested tests:
run `lf t55xx resetread` on both tags and compare the plots or post traces to attempt to ascertain exact starting point of the repeating binary.
simulate against the reader to see if single bit changes work and what combinations don't or how it changes the read number.
get/identify more valid raw to printed ID samples for more analysis.
attempt `lf t55xx detect` to see if the original tag is a t55xx and if it is unlocked"
I did not know the command exists.
Time again to update Gaucho's client Setting file
Offline
bad luck:
pm3 --> lf simask c 64 i b d FFFF0000113948b5
no respons from reader.
like you said before,we need more samples. more real cards are coming so I can do more 'lf t55xx resetread' but maybe in the meantime we can use a script to simulate a lot of variations to get valid card numbers to figure out the correct CRC?
The cards are coming in a few days,I expect them on Tuesday.
Last edited by hexa3e8 (2016-07-23 21:46:48)
Offline
here we continue, I have some more cards now to 'donate' to this wonderful forum.
the fun thing is that I have 3 cards with increasing numbers, maybe that will facilitate the process.
1410-00-0029-4467
1410-00-0029-4468
1410-00-0029-4469
I wanted to post the raw data with 'lf t55xx resetread' but I cannot get the proxmark3 to run anymore
I did a 'git pull' and then a 'make clean && make all' but then al sorts of errors occurred both on ubuntu 16 (even after a clean reinstall) and even on my ubuntu 14 stable proxmark3 backup laptop.(Before both worked fine) So until I have figured out what went suddenly wrong I cannot post those raw data. I guess I will have to make a new post about this, for the curious ones I put the error also here, maybe it is a simple fix.
no errors at the beginning only at the end
gcc -O3 -Wall -DLUA_COMPAT_ALL -DLUA_USE_LINUX -c -o ltablib.o ltablib.c
gcc -O3 -Wall -DLUA_COMPAT_ALL -DLUA_USE_LINUX -c -o loadlib.o loadlib.c
gcc -O3 -Wall -DLUA_COMPAT_ALL -DLUA_USE_LINUX -c -o linit.o linit.c
ar rcu liblua.a lapi.o lcode.o lctype.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o lbitlib.o lcorolib.o ldblib.o liolib.o lmathlib.o loslib.o lstrlib.o ltablib.o loadlib.o linit.o
ranlib liblua.a
gcc -O3 -Wall -DLUA_COMPAT_ALL -DLUA_USE_LINUX -c -o lua.o lua.c
gcc -o lua lua.o liblua.a -lm -Wl,-E -ldl -lreadline -ltermcap -lncurses
/usr/bin/ld: cannot find -lncurses
collect2: error: ld returned 1 exit status
make[2]: *** [lua] Error 1
make[2]: Leaving directory `/home/hexa3e8/Downloads/proxmark3/liblua'
make[1]: *** [linux] Error 2
make[1]: Leaving directory `/home/hexa3e8/Downloads/proxmark3/liblua'
make: *** [lua_build] Error 2
root@ubuntuLaptop:/home/hexa3e8/Downloads/proxmark3/client# ./proxmark3 /dev/ttyACM0
bash: ./proxmark3: No such file or directory
root@ubuntuLaptop:/home/hexa3e8/Downloads/proxmark3/client#
Offline
on your issue, see http://www.proxmark.org/forum/viewtopic … 243#p23243 might be the fix...
I look forward to new traces. (btw, now that we know how to correctly identify the start of stream you can use any method of getting a lf stream. (lf read - data samples, lf search, or lf t55xx resetread) and we will be able to get the right data.
Offline
@marshmellow thanks for the quick answer, I was just trying the solution from @osys, fortunately you posted the same, It has fixed my problem
apt-get install libncurses5-dev
thanks. back online (version 16 and 14)
Last edited by hexa3e8 (2016-07-27 19:47:26)
Offline
294467 http://pastebin.com/ePGaP7XD Raw: ffad7730220001ffffad7730220001ff
294468 http://pastebin.com/6gXwehx8 Raw: ffad772e200001ffffad772e200001ff
294469 http://pastebin.com/izdm8s0z Raw: ffad772c260001ffffad772c260001ff
hopefully everything is uploaded the right way.
edit:(I added also the raw)
Last edited by hexa3e8 (2016-07-27 20:56:47)
Offline
Your samples needs to be trimmed,
data ltrim 210
data raw ab 0 64 1 0
data print x
Offline
data:
294467 -- FFFF0000294467EE
294468 -- FFFF0000294468EF
294469 -- FFFF0000294469EC
i see no easy CRC calc currently...
Last edited by marshmellow (2016-07-27 22:53:39)
Offline
Don't know if I have something here but it fits for the above three samples.
Add all nibbles. xor sum with 0xB2.
f+f+f+2+9+4+4+6+7 == 5C ^ B2 = EE
f+f+f+2+9+4+4+6+8 == 5D ^ B2 = EF
f+f+f+2+9+4+4+6+9 == 5E ^ B2 = EC
[edit] nop, didn't match up with the two first samples.
Offline
I think you are on to something. Xor the cs by 2 and now the samples increment in order. I can build on that maybe
Offline
@hexa3e8 could you try:
FFFF0000113948A8
FFFF0000123949AE
FFFF0000333333B3
FFFF00004567894F or FFFF00004567894E
?
Last edited by marshmellow (2016-07-28 02:33:10)
Offline
I have been waiting all day to test it, finally I can do it.
FFFF0000113948A8 = ok (Simulating with clk: 64, invert: 1, encoding: 2, separator: 0, n: 8192 )
FFFF0000123949AE = ok (Simulating with clk: 64, invert: 1, encoding: 2, separator: 0, n: 4096 )
FFFF0000333333B3 = no reaction from reader (Simulating with clk: 64, invert: 1, encoding: 2, separator: 0, n: 8192 )
FFFF00004567894F = no reaction from reader (Simulating with clk: 64, invert: 1, encoding: 2, separator: 0, n: 4096 )
FFFF00004567894E = no reaction from reader ( Simulating with clk: 64, invert: 1, encoding: 2, separator: 0, n: 8192 )
I noticed the difference between n:8192 and sometimes the half of it 4096), Is 8192 a longer signal (more bites?) Here both a result with 4096 and 8192
I have now also another 2 cards with code 1410-00-0029-4470 (and 4471) Do you want also these samples?
I am getting more and more curious, I am calculating and learning.(learning calculating )
Last edited by hexa3e8 (2016-07-28 20:12:08)
Offline
294467 -- FFFF0000294467EE results in reader: 14100000294467
294468 -- FFFF0000294468EF results in reader: 14100000294468
294469 -- FFFF0000294469EC results in reader: 14100000294469
294470 -- FFFF0000294470?
294471 -- FFFF0000294471?
I thought I could guess 70? ,but so far no luck
Offline
294470 should be F7
294471 should be F4
more samples the better
Offline
sure?
FFFF0000294470F7 and FFFF0000294471F4 somehow dont work. I tried several times and in between also the 67,68 and 69 (they work)
I will paste the other traces in pastbin, coming in a few minutes.
Offline
card 70: http://pastebin.com/H4hnGbgt lf search
card71: http://pastebin.com/f1MX6mey lf search
card71: http://pastebin.com/bqsm2iJ0 lf t55xx resetread
Offline
interesting:
FFFF0000294470E7
FFFF0000294471E4
Offline
try FFFF0000333333A3 ? or C3?
Last edited by marshmellow (2016-07-28 21:27:04)
Offline
correct!
294467 -- FFFF0000294467EE results in reader: 14100000294467
294468 -- FFFF0000294468EF results in reader: 14100000294468
294469 -- FFFF0000294469EC results in reader: 14100000294469
294470 -- FFFF0000294470E7 results in reader: 14100000294470
294471 -- FFFF0000294471E4 results in reader: 14100000294471
Offline
FFFF0000333333A3 works! FFFF0000333333C3 not.
Last edited by hexa3e8 (2016-07-28 21:25:44)
Offline
ok, there might be a modifier that adjusts the calc in some situations... looking into it.
Offline
it looks like it is lowering the second last byte with 1 after your calculation in some cases.
FFFF0000333333B3 -> FFFF0000333333A3
FFFF0000294470F7 -> FFFF0000294470E7
FFFF0000294471F4 -> FFFF0000294471E4
Offline
correct. it may have something to do with the fact that there is no HEX in their Hex number. (only 0-9 instead of 0-F)...
Offline
sorry to keep adding tests but more samples the better:
FFFF0000294479 EC or FC
FFFF0000294480 06 or F6 or 07 or F7
Offline
no problem for more tests.keep them coming. but unfortunately none of the latest examples work.
FFFF0000294479EC
FFFF0000294479FC
FFFF000029448006
FFFF0000294480F6
FFFF000029448007
FFFF0000294480F7
Offline
FFFF0000294472E5 for card 72 works
Offline
some more:
FFFF0000294473 EA (FA)
FFFF0000294474 EB (FB)
FFFF0000294475 E8 (F8)
FFFF0000294476 E9 (F9)
FFFF0000294477 EE (FE)
FFFF0000294478 EF (FF)
Offline
and:
FFFF0000294459 DC (CC)
FFFF0000294460 E7 (D7)
FFFF0000294461 E4 (D4)
FFFF0000294462 E5 (D5)
FFFF0000294463 EA (DA)
FFFF0000294464 EB (DB)
FFFF0000294465 E8 (D8)
FFFF0000294466 E9 (D9)
Offline
none for post 82, I try post 83 now
Last edited by hexa3e8 (2016-07-28 22:07:04)
Offline
... error posting.
Last edited by marshmellow (2016-07-28 22:05:39)
Offline
hmmm FFFF0000294473EA didn't work huh....
Offline
yes 4 more positive results!
FFFF0000294463EA
FFFF0000294464EB
FFFF0000294465E8
FFFF0000294466E9
(the rest no response)
Offline
positive in order.
FFFF0000294463EA
FFFF0000294464EB
FFFF0000294465E8
FFFF0000294466E9
FFFF0000294467EE
FFFF0000294468EF
FFFF0000294469EC
FFFF0000294470E7
FFFF0000294471E4
FFFF0000294472E5
Offline
FFFF0000294473DA
FFFF0000294474DB
FFFF0000294475D8
FFFF0000294476D9
Offline
FFFF0000444444F6 ?
Offline
Welcome to the copy and paste party here and YES @iceman those work too.
and post #90 too! FFFF0000444444F6
Last edited by hexa3e8 (2016-07-28 22:28:44)
Offline
As I figure it, its only a simple byte add of the bytes and a final xor with 0x3A
Offline
Cool! shall I try another one to make sure? Then I have to study how to calculate it by myself. I need a hex calculator..... or are you using excel or something simular for those xor etc?
Offline
just the simple calculator in windows.. it has a programmer mode which deals with hex,dec,oct,bin and stuff like XOR.
Offline
55+55+55 = FF
FF ^3A = C5
FFFF0000555555c5
Question is if we change the zeros to 11 and see what your reader will print?
11+11+55+55+55 = 21 ^3A = 1B
--> FFFF11115555551B
Offline
Great, I see it now,on windows 10 it is actually a nice calc, but I am using more and more linux nowadays (at work still windows).
FFFF11115555551B works great: the result: 1410111155555
I would love to continue and test some more options but unfortunately I have to sign out for now. thanks @marshmellow and @iceman for outsmarting the usb reader, and again a little piece of your knowledge. So now if a person wants to make his/her own jablotron rfid card it is possible. Is this calculation something for in the iceman fork? or are we testing first some more limits of numbers.
Last edited by hexa3e8 (2016-07-28 23:01:58)
Offline
Ok, then we have verified that all numbers after FFFF is included in checksum. 1410 mapping is maybe fixed, since its not transfered over air.
I'm guess we will have a jablotron demod (with sim and clone) soon in a fork...
Offline
. I was close.
Offline
Ran out of time
Offline
If my byte add loop wasn't adjusted for one's complement I've should have gotten the xor right the first time
And you got lead the same way as I because of it. Sorry. I bet @Asper would had solved it direct
Offline