Kantech ioProx

14400bps · 2014-10-22 05:07:00

ok ... so I think I bricked my proxmark :-(

This is what I did.

- Setup build environment on 64 bit Ubuntu VM inside VMWare player on Windows 7
- Applied my patch to lfops.c
- ran make - it built fine
- flashed my flash

[== Undefined ==]
root@home3:~/proxmark3/client# ./flasher /dev/ttyACM0 ../armsrc/obj/osimage.elf 
Loading ELF file '../armsrc/obj/osimage.elf'...
Loading usable ELF segments:
1: V 0x00118000 P 0x00118000 (0x00015a3c->0x00015a3c) [R X] @0xb8
2: V 0x00200000 P 0x0012da3c (0x000028e0->0x000028e0) [RWX] @0x15af8
Note: Extending previous segment from 0x15a3c to 0x1831c bytes

Waiting for Proxmark to appear on /dev/ttyACM0. Found.

Flashing...
Writing segments for file: ../armsrc/obj/osimage.elf
 0x00118000..0x0013031b [0x1831c / 194 blocks].................................................................................................................................................................................................. OK

Resetting hardware...
All done.

Have a nice day!

Reconnected proxmark and it just keeps clicking and flashing in a loop. ... not a nice day.

I was reading that I should match my bootloader with OS. Is that what messed it up? I tried to flash my bootloader, but it didn't work. It said "Attempted to write bootloader but bootloader writes are not enabled" but maybe that's good because I'm pretty sure it's safe to say I have no idea what I'm doing at this point.

14400bps · 2014-10-22 05:20:55

... ok crisis averted. I went back to my windows laptop that I knew had my old firmware. Flashed that and I'm back in business. Now ... what am I doing wrong? I'm guessing that I have to flash my boot first before I attempt to flash my os image next time. Is that right?

asper · 2014-10-22 07:15:04

Yes, you need to flash the bootloader because the new code has changes needed for the new fpga+os; usually it is not necessary to update also the bootloader, you need to have a look at the sources to see if it has been changed.

14400bps · 2014-10-23 04:35:25

Thanks guys. I finally finished the patch. You can grab both the firmware as well as the source patch from my blog http://lab.florian.ca/?p=74

Please test drive it. I'm still trying to figure out how to do a pull request so that it's included in github.

Now that this works, maybe we can figure out the check sum and another mystery code (bits 9 - 16).

app_o1 · 2014-10-23 05:33:36

Nice work !

proxmark3> lf io fskdemod
#db# 00000000 padding   (always 0)
#db# 0        separator (always 0)
#db# 11110000 another separator? (always 1110000?)
#db# 1        separator (always 1)
#db# 00111011 facility?
#db# 1        separator (always 1)
#db# 00000001 version?
#db# 1        separator (always 1)
#db# 10101110 unique code part 1
#db# 1        separator (always 1)
#db# 10110101 unique code part 2
#db# 1        separator (always 1)
#db# 01110000 CRC? checksum?
#db# 11       separator (always 11)
#db#
#db# XSF(01)3b:44725 (00784ee03aedadc3)

Last edited by app_o1 (2014-10-23 05:37:08)

holiman · 2014-10-23 07:48:18

Hi, I haven't checked your patch yet, but when the initial ioprox implementation was committed, I voiced some concerns - the code was really hacked together. So I refactored it here https://github.com/holiman/proxmark3/tree/ioprox_fixes . However, since I didn't have any ioprox to test with, I never committed it to main. And then pentura_prox went offline, and never had time to test the modified code..

Would anyone here be willing to check if these modifications can be incorporated/merged with the changes above ? They also make the operation 'lf hid fskdemod' a lot more stable.

14400bps · 2014-10-23 15:03:12

I like how you cleaned it up. Makes your code much more readable. However, some of the offsets for decoding the XSF seem incorrect. My tweaks were quite minor, compared to your re-factoring, so I'm tempted to take yours as a base, and then add my tweaks to it. How do we go about comitting to the main repository? I wouldn't want to be here in few months having the same conversation of how do we merge two different branches that were sitting on someone's machine all this time.

Last edited by 14400bps (2014-10-23 15:16:34)

holiman · 2014-10-23 20:28:55

Yeah, Pentura_prox confirmed that the ioprox functionality stopped working with my changes, but he didn't have the time to fix it with me. How about this;

1. I update the branch with everything that has happened in head since then. I think I can do that this weekend. I'll make sure that lf hid fskdemod works.
2. You fix the ioprox functionality in my branch. Either by sending me diffs or doing pull-requests, whatever suits you best.
3. Once you confirm that ioprox works, I'll commit it to main.

No need for the code to be sitting on a machine for a few months this time if you have access to ioprox tags. (I actually tried to order from amazon, but the supplier didn't ship to Sweden. It was extremely annoying not to be able to commit the improved code because of that).

14400bps · 2014-10-24 05:18:21

Sounds like a plan. Let me know when 1) is done.

holiman · 2014-10-25 15:45:22

Yesterday evening, I merged with head, so now my branch contains some stuff that Izsh made. I merged it so it compiles, but I haven't yet verified that I the functionality is intact. I hope to do that today or tomorrow.

holiman · 2014-10-25 21:47:07

I've confirmed that the code still works, i.e, that the changes I made, which primarily concerns 'lf hid fskdemod' and 'lf io fskdemod' are as before: 'hid fskdemod' now does not produce false readings, but 'io fskdemod' probably does not work correctly.

Here's the code https://github.com/holiman/proxmark3/tree/ioprox_fixes
Beware, it's in a branch on my repo. So, first clone the repo:

git clone git@github.com:holiman/proxmark3.git

Then fetch the branch:

cd proxmark3/
git checkout -t origin/ioprox_fixes

And then make you changes. If small, you can paste the git diff here. If you're on github, a pull request would be even nicer.

14400bps · 2014-10-27 04:46:44

Thanks. It may take me a couple of weeks before I can get to this. But I will do it.

14400bps · 2014-11-08 06:24:07

I was going to start working on this, but found out my proxmark died :-(. I took it out of my drawer, to load the new code to it, plugged into my machine and nothing (no light, no click noise). Even tried a different computer and on that one I get "USB malfunction message" still no light or click. It failed before I even tried flashing anything. I will try to find out if rysc corp will honor their warranty. Otherwise it's game over for me...

Last edited by 14400bps (2014-11-08 06:25:38)

14400bps · 2014-11-09 04:43:01

This is embarrassing - I got my antenna and PC connection mixed up. Anyway.. I'm back in business.

holiman - I found the following problems when running your code:

- I get a reading even when no IO prox tag is placed on the antenna. What's worse I get the same reading when I do place a tag on the antenna. Clearly it's not reading from the antenna - I don't know where it's getting the numbers from. It's always the same reading regardless on what's on the antenna (047f4dc8abffffff). HID seems ok although I don't have enough experience with it to test that properly.
- Dbprintf shows up weird. I expect 0's and 1's. It shows me decimal numbers instead.

I tried to see if I could spot where things went wrong, but I'd have to dig deeper. I'm rusty at C, so it will take me too much time to fix these bugs. Unless you are sure how to fix these problems without having a ioprox tag on you, I suggest we change strategy. Let's start with working code (my patch) and then you refactor that code little bit at a time. I can test at each re-factoring step. You send me patches, and I tell you pass/fail. In other words you'll program and I'll do QA. We can take this offline, unless there are others who are willing to do QA for holiman (it would be good if there were). You can find my email address at www.florian.ca

I do want to get your refactored code committed, because you did clean it up nicely - but of course we have to do it in a way that doesn't break functionality.

holiman · 2014-11-10 18:01:11

14400bps wrote:

This is embarrassing - I got my antenna and PC connection mixed up. Anyway.. I'm back in business.

Been there, done that

Anyway, perhaps it would be better if you could just dump the reading of an ioprox tag, and send the dump to me. I'll write you an email about it.

marshmellow · 2014-12-17 16:03:56

holiman wrote:

I've confirmed that the code still works, i.e, that the changes I made, which primarily concerns 'lf hid fskdemod' and 'lf io fskdemod' are as before: 'hid fskdemod' now does not produce false readings, but 'io fskdemod' probably does not work correctly.

looks like this made it into the master, i've patched it and fixed lf io fskdemod and created a pull request this morning. i also added the option to only look for 1 tag by placing a 1 after the fskdemod for both lf hid and lf io, instead of always looping until the button is pressed.

EDIT: I also just realized within the pull request was my adjustment to the readout of lf hid fskdemod which give the raw ID as always but it also attempts to decode a few common formats with the facility code (it will also attempt to tell you the bit length of the format used) helps me decode at a glance.

Last edited by marshmellow (2014-12-17 21:20:57)

holiman · 2014-12-18 08:33:22

Great work! I'll take a look and accept it!

holiman · 2014-12-18 09:02:36

Merged

Omikron · 2014-12-18 23:26:55

14400bps wrote:

This is embarrassing - I got my antenna and PC connection mixed up. Anyway.. I'm back in business.
- I get a reading even when no IO prox tag is placed on the antenna. What's worse I get the same reading when I do place a tag on the antenna. Clearly it's not reading from the antenna - I don't know where it's getting the numbers from. It's always the same reading regardless on what's on the antenna (047f4dc8abffffff). HID seems ok although I don't have enough experience with it to test that properly.

I can confirm the same problems. I have several ioProx tags and I can't actually get a single clean read out of io fskdemod. Even with no tag in the antenna field, the pm3 reports constantly changing cards numbers.

marshmellow · 2014-12-19 00:21:06

Omikron, are you working with the latest git version? (Not the precompiled version, but the one you have to compile?)

Omikron · 2014-12-19 00:32:13

marshmellow wrote:

Omikron, are you working with the latest git version? (Not the precompiled version, but the one you have to compile?)

Always. :-)

marshmellow · 2014-12-19 00:34:51

Could you post a trace I could test. The latest changes posted this morning fixes the issues for the few tags I have.

iceman · 2014-12-19 00:42:33

(will all the latest patches)
Running it without a tag on the antenna yields this:

pm3 --> lf io fskde
#db# XSF(80)08:424 (00552115000aa001)
#db# XSF(144)00:5513 (0055000900aa2528)
#db# XSF(18)2a:10277 (0048055129409508)
#db# XSF(01)08:42277 (0050010015289411)
#db# XSF(162)2a:40981 (0040054a25045555)
#db# XSF(04)12:43605 (0054a2504555554a)
#db# XSF(32251)ff:154 (00415ff8f8026ffa)
#db# XSF(1978)fa:24573 (004dff40e2ffff48)
#db# XSF(00)e0:0 (0077fc0000000000)
#db# XSF(31995)ff:154 (0041ff00f8026ffa)
#db# XSF(1978)fa:24573 (004dff40e2ffff48)
#db# XSF(00)e0:0 (0077fc0000000000)
#db# XSF(31995)ff:154 (0041ff00f8026ffa)
#db# XSF(1978)fa:24573 (004dff40e2ffff48)
#db# XSF(00)e0:0 (0077fc0000000000)
#db# XSF(31995)ff:154 (0041ff00f8026ffa)
#db# XSF(1978)fa:24573 (004dff40e2ffff48)
#db# XSF(00)e0:0 (0077fc0000000000)
#db# XSF(31995)ff:154 (0041ff00f8026ffa)
#db# XSF(1978)fa:24573 (004dff40e2ffff48)
#db# XSF(00)e0:0 (0077fc0000000000)
#db# XSF(31995)ff:154 (0041ff00f8026ffa)
#db# XSF(1978)fa:24573 (004dff40e2ffff48)
#db# XSF(00)e0:0 (0077fc0000000000)
#db# XSF(31995)ff:154 (0041ff00f8026ffa)
#db# XSF(1978)fa:24573 (004dff40e2ffff48)
#db# XSF(00)e0:0 (0077fc0000000000)

marshmellow · 2014-12-19 04:23:54

That is possible with static, not abnormal. The hid demod doesn't do that often because of the unique start bits and the Manchester encoding. Io prox does not have these items to help weed out false reads. I can probably adjust the code to test the strength before demoding. I'll do some testing tomorrow.

Last edited by marshmellow (2014-12-19 04:25:24)

Omikron · 2014-12-19 04:25:53

iceman wrote:

(will all the latest patches)
Running it without a tag on the antenna yields this:
<snip>

I get the same behavior, but at least with your pm3 you're getting the same ghost tag over and over. On mine the tag keeps changing.

marshmellow · 2014-12-19 04:28:46

Can anyone confirm the io clone still works? I don't have an actual io reader.

holiman · 2014-12-19 09:05:46

That XSF-format. Extensible Secure Format - right ? Is that something that isn't cracked yet? Do we know how it maps to a certain ID-value, and how to construct our own if we want to sequentially simulate different ids?

marshmellow · 2014-12-19 15:15:15

holiman wrote:

That XSF-format. Extensible Secure Format - right ? Is that something that isn't cracked yet? Do we know how it maps to a certain ID-value, and how to construct our own if we want to sequentially simulate different ids?

we do not have the algorithm that generates the 8 bit checksum (hash?) so we cannot generate our own IDs.

iceman · 2014-12-19 15:56:18

Does someone have information on it?

marshmellow · 2014-12-19 19:14:49

I have created a pull request with some fixes to FSK demoding as well as adding offline demoding for fsk raw - fsk hid and fsk io.
I have cleaned up false positives some.

it'd be great if some others can test with their antennas and cards (as there seems to be quite a bit of variance).

Last edited by marshmellow (2014-12-19 21:00:21)

marshmellow · 2014-12-19 19:15:49

now on to Manchester and ask modulation. it has always given me trouble...

holiman · 2014-12-19 22:41:10

If were doing changes to really old stuff which has been in use for years, it would be good if we could use the existing traces to verify that atleast it didn't break anything, and preferrably that it got better. The traces are here https://github.com/Proxmark/proxmark3/t … ter/traces. Would it be possible for you to use those, alternatively to supply a few new ones which are taken from your tags? Over time, I think that would benefit the source code. As it is, we keep running into walls where someone sometime had a tag, but he is long gone and it's difficult to verify if something stll works.

As for manchester modulation/demodulation - what are your plans? We already have that, no? (and I guess you mean demodulation, as modulation is pretty trivial - since there are no error sources)

marshmellow · 2014-12-20 00:08:44

1st, i agree. I tested 40 to 50 hid tags and a few of the traces. I will test more of the traces as you suggest as well... I'd like to make functions that work with more than one specific format and configuration. You made a great start with FSK. I'm just fixing io prox while trying to keep all other FSK demod possible. I don't mind criticism of the code either, please improve as you see fit. My c is a little rusty.

Manchester can be a single function to translate 10 to 1 and 01 to 0, then it can be used on its own and by other functions and any modulation. As it is it is built in to the hid demods and the Manchester demos includes ask demodulation, but it is implemented differently in various areas. Also it depends on clipped waves to function, some tags/antennas don't provide this. This is easy to fix. For backwards compatibility should I create new function names?

marshmellow · 2014-12-20 00:12:18

As for ask, we don't really have a way to demod ask that is not Manchester encoded.

marshmellow · 2014-12-20 00:48:52

I looked further at the fsk traces available. I ran them then against the data fskdemod from version 0.0.5 (i had around) and they did not result at all what the demod should be (i can manually demod them by eye from the grid) (except the 1 hid trace). i ran them with my changes and I can get close, but the traces appear to have all been clipped, this affects the new threshold value. i will look and see if i can fix it. but my patch did not break it, it actually is a lot closer to the correct demod, and if you don't clip the traces it should function better. but there is probably room for improvement here. i will also test some keyfobs when i get a chance as well as another antenna i'm making in the near future.

there appears to be better traces for manchester than fsk, i will be sure to use those as test subjects as i play with ask and manchester.

holiman · 2014-12-20 09:52:47

marshmellow wrote:

I'd like to make functions that work with more than one specific format and configuration.

Yes, that is good. It's basically whats been done in RFIDler (see this blog post for more details https://www.kickstarter.com/projects/17 … sts/604981), which makes it very easy do define a tag in terms of attributes (instead of implementing specific functions).
Example definition of hid 26:

        case TAG_TYPE_HID_26:
            //RFIDlerConfig.FrameClock= 765; // 130.7 KHz (134KHz breaks emulation)
            RFIDlerConfig.FrameClock= 800; // 125 KHz
            RFIDlerConfig.Modulation= MOD_MODE_FSK2;
            RFIDlerConfig.PotHigh=  110;
            RFIDlerConfig.DataRate= 50;
            RFIDlerConfig.DataRateSub0= 8;
            RFIDlerConfig.DataRateSub1= 10;
            RFIDlerConfig.DataBits= 96;
            RFIDlerConfig.TagType= tag;
            RFIDlerConfig.Repeat= 20;
            RFIDlerConfig.Timeout= 13000; // timeout in uS (note with prescaler of 16 max is 13107)
            RFIDlerConfig.Sync[0]= 0x1D;
            RFIDlerConfig.Sync[1]= 0x55;
            RFIDlerConfig.Sync[2]= 0x00;
            RFIDlerConfig.Sync[3]= 0x00;
            RFIDlerConfig.SyncBits= 16;
            RFIDlerConfig.RWD_Wake_Period= 1000;
            break;

And that is a *very' good model. I love it. (However, since Adam has done such great job on this, I personally am a bit reluctant to put the time into doing the same thing for pm3 (I have a rfidler beta), and would rather spend my available tinkering-time on HF. )

You copied some armsrc-code into client right ? Would it be possible to put the code inside a file in the include-directory? That way, both client and arm could share the exact same pieces of source code. Regarding function names, it doesn't make any difference in regards to backwards compatibility (right?).. but it could be a good idea.. you decide.

ASKDemod could basically take the same approach as rffidler, set pot-high and pot-low, transition to 1 when it passes pot-high, transition to low when it passes pot-low.

marshmellow · 2014-12-20 14:18:21

It might be possible to use the same code in the arm and client. I was having trouble doing that since bugbuf and graphbuffer are different types and holds different data. I haven't looked far enough into the code to identify the conversion of the data in graphbuffer and put it in bigbuf. (Probably easy but I didn't get that far yet) If that can be done we could use the same code in an include file.

Askdemod, to be most accurate we need to consider the clock, and identify a starting point that lines up properly. What you describe is ask-manchester demodulation., not ask only. It would not work for the tags this and other forum posts. http://www.proxmark.org/forum/viewtopic … 227#p13227. But the ask functions and mandemod functions separate could be used for ask only tags and ask/mandemod tags and the mandemod separate could even be reused in hid demod.

holiman · 2014-12-20 15:18:57

marshmellow wrote:

Askdemod, to be most accurate we need to consider the clock, and identify a starting point that lines up properly. What you describe is ask-manchester demodulation., not ask only.

Then you misunderstood me. What I mean by askdemod is, in the simplest form, a raw digitization of signal to two levels; one a zero. The simplest algo is to apply a threshold, anything above=>1, below=>0. However, when the analog signal crosses the threshold, there may be a bit of noise, and it may jump a bit across the threshold at that point, leading to errors in the demodulated signal. To counter that, you can use two thresholds. In order for the output to go to 1, the signal needs to cross a high threshold, and once that's happened, in order for it to go to 0 again it would have to succomb the gap all the way to the low-threshold. So, on a scale of 0-100, the low threshold is maybe at 30 and the high threshold at 70. Small fluctuations won't cause bit errors.

It could be even more elaborate:
1. First run, use single threshold (middle of range), average the analog value of all 1:bits and all 0:bits (independently).
2. So, e.g. the average 1-value may turn out to be not 100, but 71 because we had a weak signal. The average 0-value may be 3.
3. Set pot-high to 71-(20% of range) => 51
4. Set pot-low to 3+(20% of range) => 23
5. Second run, using double thresholds.

There's no need to mix in clock in askdemod,as I see it. If the simple one-threshold-method is used, then yes, I can see why one would want to start using a clock in order to remove the bit errors. But I think it's cleaner not to mix in a clock in the askdemod step.

EDIT: I'm probably wrong: the term askdemod probably means including clock. However, I stil think that programmatically, the two steps of digitization on the y-axis and quantization on the x-asis (clock) can be kept separate.

Last edited by holiman (2014-12-20 15:24:06)

marshmellow · 2014-12-20 17:10:26

http://www.proxmark.org/forum/viewtopic.php?id=183. Why do I feel like what I am looking for was done long ago but then changed by others to narrow its purpose. I'm going to look to see if the old code exists somewhere.

EDIT: i think i found the original askdemod in the google code, https://code.google.com/p/proxmark3/sou … nd.cpp?r=2 but askdemod is quite different form what this post is really about so i will start a new post on this if anyone wants to discuss.- ultimately i think i will just add a function to output binary from askdemod based on a clock value.

sorry for the tangent.

Last edited by marshmellow (2014-12-20 20:07:55)

marshmellow · 2014-12-22 23:46:46

@holiman, I believe i've tested the FSK code thoroughly, it functions much better with the io prox and doesn't harm the HID prox with my existing pull request.

midnitesnake · 2014-12-23 10:51:14

agreed

holiman · 2014-12-23 12:44:07

I'm away from my laptop this week, unable to commit/accept pull requests. I'll acc when I'm back home

marshmellow · 2014-12-29 22:13:58

I now have moved the demod functions into it's own common .c and .h file that now shares the same code for the client and arm. this is in my fork only. i've tested it but i admit my code may not be up to some peoples standards, as my C is very rusty... (also in this new file is new ASK demod and manchester decode functions.)

i did notice that the lf hid fskdemod is a bit slower now (looping to get more info about the tag id...)

other than that it functions well for me. anyone want to take a look?

Last edited by marshmellow (2014-12-29 22:14:35)

lanix13 · 2015-01-08 00:26:20

Guys, sorry to jump in on the party here. I spent some time today looking at a stack of sequencial ioprox cards that I have and doing some investigation and such. I hope this makes sense, I haven't looked at the latest code yet to see how I can help out.

It appears that the sequencial cards in a stack range from a number like this:
0000000001111000011110011010000000110001100011111111110001000111
to this
0000000001111000011110011010000000110001100010001000111111111111

if you split this up into the different spacers and 8bit sections, it gets interesting, lets just look at the last chunks.
low num:
11111111 1 00010001 11
high num:
00010001 1 11111111 11
while the first set of 8bits increment the second set of 8bits decrements in equal order all the way through.

I am working on some interesting code to generate all card numbers for the given site code bits. I will share when I am done, unless someone beats me to it.

marshmellow · 2015-01-09 16:14:04

the obvious calc is to xor EE with the last 8 bits of the Card number. But it works only with odd number and EE changes with each group.

Last edited by marshmellow (2015-01-09 16:33:44)

marshmellow · 2015-01-09 16:58:33

You have the full group of cards between 11 and ff and they all increment this way?

lanix13 · 2015-01-09 17:51:48

I don't actually have the full group, only about 5 cards, but I noticed how they behaved so I tried to find the top number card and the bottom number card. I was verifying as I went on the reader and software I had access to. I couldn't find a way to go above or below those two numbers that would still work.

marshmellow · 2015-01-09 17:53:15

OK that helps.

marshmellow · 2015-01-16 18:29:48

@lanix13, do you still have a reader available you can spoof tags on?

if we can get a large number of samples in different groups that function we might have a better chance at identifying the checksum.

i can give you a few more "Known" working tag numbers to run through and see how many around it we can get, if you're up to it. (I don't have a reader )

lanix13 · 2015-01-17 05:24:10

I will have access for a little longer wile I do some work for this client. I would love to get it figured out, it has been driving me nuts.

Proxmark3 community

Announcement

#51 2014-10-22 05:07:00

Re: Kantech ioProx

#52 2014-10-22 05:20:55

Re: Kantech ioProx

#53 2014-10-22 07:15:04

Re: Kantech ioProx

#54 2014-10-23 04:35:25

Re: Kantech ioProx

#55 2014-10-23 05:33:36

Re: Kantech ioProx

#56 2014-10-23 07:48:18

Re: Kantech ioProx

#57 2014-10-23 15:03:12

Re: Kantech ioProx

#58 2014-10-23 20:28:55

Re: Kantech ioProx

#59 2014-10-24 05:18:21

Re: Kantech ioProx

#60 2014-10-25 15:45:22

Re: Kantech ioProx

#61 2014-10-25 21:47:07

Re: Kantech ioProx

#62 2014-10-27 04:46:44

Re: Kantech ioProx

#63 2014-11-08 06:24:07

Re: Kantech ioProx

#64 2014-11-09 04:43:01

Re: Kantech ioProx

#65 2014-11-10 18:01:11

Re: Kantech ioProx

#66 2014-12-17 16:03:56

Re: Kantech ioProx

#67 2014-12-18 08:33:22

Re: Kantech ioProx

#68 2014-12-18 09:02:36

Re: Kantech ioProx

#69 2014-12-18 23:26:55

Re: Kantech ioProx

#70 2014-12-19 00:21:06

Re: Kantech ioProx

#71 2014-12-19 00:32:13

Re: Kantech ioProx

#72 2014-12-19 00:34:51

Re: Kantech ioProx

#73 2014-12-19 00:42:33

Re: Kantech ioProx

#74 2014-12-19 04:23:54

Re: Kantech ioProx

#75 2014-12-19 04:25:53

Re: Kantech ioProx

#76 2014-12-19 04:28:46

Re: Kantech ioProx

#77 2014-12-19 09:05:46

Re: Kantech ioProx

#78 2014-12-19 15:15:15

Re: Kantech ioProx

#79 2014-12-19 15:56:18

Re: Kantech ioProx

#80 2014-12-19 19:14:49

Re: Kantech ioProx

#81 2014-12-19 19:15:49

Re: Kantech ioProx

#82 2014-12-19 22:41:10

Re: Kantech ioProx

#83 2014-12-20 00:08:44

Re: Kantech ioProx

#84 2014-12-20 00:12:18

Re: Kantech ioProx

#85 2014-12-20 00:48:52

Re: Kantech ioProx

#86 2014-12-20 09:52:47

Re: Kantech ioProx

#87 2014-12-20 14:18:21

Re: Kantech ioProx

#88 2014-12-20 15:18:57

Re: Kantech ioProx

#89 2014-12-20 17:10:26

Re: Kantech ioProx