Proxmark3 community

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.

Announcement

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.

#1 2014-04-02 08:24:39

gaucho
Contributor
From: France
Registered: 2010-06-15
Posts: 444
Website

NEW snoop function able to sniff LF/HF signal.

I didn't found a better section to post this thread.
Enio on this thread http://www.proxmark.org/forum/viewtopic … =1599&p=22 started developing a new FPGA and ARM FW functions able to sniff data from the HF and LF path, saving data on the ARM memory or directly transferred to the pc (TBD).
HE also posted a debug full image with fixed delay and fixed sampling frequency and fixed path (HF).
This is a fundamental function that will allow easy study and exploit of new tags and new protocols.
Here Enio can upload details on its progess and share questions and answers.

Last edited by gaucho (2014-04-02 08:25:07)

Offline

#2 2014-04-02 08:30:20

gaucho
Contributor
From: France
Registered: 2010-06-15
Posts: 444
Website

Re: NEW snoop function able to sniff LF/HF signal.

I'll continue from last enio post:

Enio wrote:

Im very low on time too, sadly - i hope i can get further at the weekend.

Edit: I have plans (after i finish the generic fpga passthru, allowing these hf snoops) to extend it. I want to passthru the data directly to the pc, kind of similar to the circular buffer thing in 14443a part - just with the addition to have a modulation detection included, basically to find the interesting parts. That way we can fill the BigBuffer on ARM with up to 24 Mbit/s (3MS/s) and hand the interesting data over to pc with up to 12Mbit/s (1.5MS/s) with help of usb 1.1. Depending on the size of the gaps between the transmissions, we might be able to snoop the interesting parts of a whole transmission on high detail, not just 40k samples - and if that wont work due to too long transmissions, at least with 13.56 Mhz clock on ssc (13.56 Mbit/s = 1.695 MS/s) it should work out. (We receive on ARM with ~1.7 MS/s and send them over with 1.5 MS/s, the gaps with no modulation should allow to empty the transmit buffer).

This would be really cool imho, im just not exactly sure how to put that into code.

My Idea is to reduce the sample value to be 0x01 to 0xFF (thats -127 to 127 - if adc finds a 0x00 make it 0x01). As i always send 2 samples per frame on ssc we might be able to use 0x00 to mark that a nonmodulated part starts and use the 2nd (or 3rd & 4rth) byte to send the length of the unmodulated part. For example if there is normal samples and then 300 samples not interesting, it would be [0xXX 0xXX ] (last normal sample) [0x00 0xFF](256 boring samples skipped)[0x00 0x2B](44 boring samples skipped) [0xXX 0xXX] (normal samples) - that way we can put it back together on plot to have the sample count (for timing stuff) between modulated data exact. This needs alot of logic in ARM (if theres enough power to not lose samples due to the calculations - i want to test how DMA works for that matter) or in FPGA - or in both.

Ill try to get a thread about all this created coming weekend, however until then, any ideas are welcome here too!

Are you sure that the 42000 samples are not sufficient to sample all the communication between tag and reader? I do not agree with you, even if i'm not sure.
I think that we should first make stable the snoop function for HF and LF path, with a dedicated path on the client menu.
We need to make it stable on saving data on the PM3 memory. Later we can think to transfer that data "real time" to the computer with an enhancement of your function.
Also digital scopes has limited memory and they use workarounds to let the user watch what they want.
For this reason on your function we will be able to change delay from trigger, number of triggers to skip, trigger level, sampling frequency, and channel input (HF/LF)

Last edited by gaucho (2014-04-02 08:34:41)

Offline

#3 2014-04-02 09:11:54

asper
Contributor
Registered: 2008-08-24
Posts: 1,409

Re: NEW snoop function able to sniff LF/HF signal.

So this will be a kind of "oscilloscope" function, isn't it?

Offline

#4 2014-04-02 09:26:19

Enio
Contributor
Registered: 2013-09-24
Posts: 175

Re: NEW snoop function able to sniff LF/HF signal.

Thank you gaucho - just so you all see what its about - this is a snoop of a Mifare ATQA [0x0400, visible as 1(Start) 0010 0000 0(odd parity) 0000 0000 1(odd parity) End(1 bit no modulation)].
BO0TL.jpg
5byaB.jpg


gaucho wrote:

Are you sure that the 42000 samples are not sufficient to sample all the communication between tag and reader?

Well, this depends on the sampling speed, with 1.695MS/s (13.56 MHz on ssp clock - the main HF freq i aim for) it will be full in no time.

gaucho wrote:

I do not agree with you, even if i'm not sure.
I think that we should first make stable the snoop function for HF and LF path, with a dedicated path on the client menu.
We need to make it stable on saving data on the PM3 memory. Later we can think to transfer that data "real time" to the computer with an enhancement of your function.
Also digital scopes has limited memory and they use workarounds to let the user watch what they want.
For this reason on your function we will be able to change delay from trigger, number of triggers to skip, trigger level, sampling frequency, and channel input (HF/LF)

Yes, maybe i didnt make that clear - extending the snoop to record continous communication for a longer period is just an idea for the future. My priority is to get the generic snoop that dumps data into the buffer till its full implemented.


On that matter, on my client i already transferred the fpga passthru to its own module and i studied the code further to understand how configuration is done - its actually quite easy and theres enough room to extend configuration "codes" to support multiple options on fpga.


As a first step i will try to get all basic stuff integrated nondestructively into the current version, and add a test command-section where itll be easy to add and remove commands. I might have to disable one MAJOR_MODE" for a while though - ill explain details when im on it. However, as this passthru is capable of doing the lf read too, in the future we might get a MAJOR_MODE freed anyways.

Last edited by Enio (2014-04-02 09:29:20)

Offline

#5 2014-04-02 10:29:29

gaucho
Contributor
From: France
Registered: 2010-06-15
Posts: 444
Website

Re: NEW snoop function able to sniff LF/HF signal.

Enio wrote:
gaucho wrote:

Are you sure that the 42000 samples are not sufficient to sample all the communication between tag and reader?

Well, this depends on the sampling speed, with 1.695MS/s (13.56 MHz on ssp clock - the main HF freq i aim for) it will be full in no time.

You don't need that high resolution. When you use that high resolution you are observing a piece of the signal, just in case you want to observe specific modulation on a specific bit. Commonly, when you understood the kind of modulation, in order to manually decode the communication (by watching the signal on the "oscilloscope"), you just need 2 samples for each bit of communication. This means that the sampling frequency can be lowered a lot.

Last edited by gaucho (2014-04-02 10:31:15)

Offline

#6 2014-04-02 11:16:16

Enio
Contributor
Registered: 2013-09-24
Posts: 175

Re: NEW snoop function able to sniff LF/HF signal.

gaucho wrote:
Enio wrote:
gaucho wrote:

Are you sure that the 42000 samples are not sufficient to sample all the communication between tag and reader?

Well, this depends on the sampling speed, with 1.695MS/s (13.56 MHz on ssp clock - the main HF freq i aim for) it will be full in no time.

You don't need that high resolution. When you use that high resolution you are observing a piece of the signal, just in case you want to observe specific modulation on a specific bit. Commonly, when you understood the kind of modulation, in order to manually decode the communication (by watching the signal on the "oscilloscope"), you just need 2 samples for each bit of communication. This means that the sampling frequency can be lowered a lot.

You might not need it if you know what you are looking for. We can already put our specific wishs into fpga code and just get the result. However if i want to visually compare a long transaction - lets say some answers of a java card - and i want to find out which parts are "interesting" to measure the cpu load my request produced -it could very well be handy to capture the whole in 1go without fiddling with various triggers.

This will just be optional, and its low in priority, but why not do it if pm3 can?

Offline

#7 2014-04-02 12:08:27

gaucho
Contributor
From: France
Registered: 2010-06-15
Posts: 444
Website

Re: NEW snoop function able to sniff LF/HF signal.

i agree with you. Just i don't think you can transfer data realtime on usb, since the windows/linux environment SLEEPs for 10 milliseconds whenever it wants, just do to its stuffs. On that time, i think you're not able to transfer anything, anyway i have no experience on usb transfer. May be there is a buffer on the usb driver on pc side. For sure the buffer on the arm is too much small. Let's see what we can do. Let's start from easy things as you already told.

Offline

#8 2014-04-02 16:38:49

Enio
Contributor
Registered: 2013-09-24
Posts: 175

Re: NEW snoop function able to sniff LF/HF signal.

gaucho wrote:

i agree with you. Just i don't think you can transfer data realtime on usb, since the windows/linux environment SLEEPs for 10 milliseconds whenever it wants, just do to its stuffs. On that time, i think you're not able to transfer anything, anyway i have no experience on usb transfer. May be there is a buffer on the usb driver on pc side. For sure the buffer on the arm is too much small. Let's see what we can do. Let's start from easy things as you already told.

These are buffered by the controller chips, no worries. A bigger problem is that these 12Mbit/s are brutto - the actual measured datarate can be 30 to 45% less. But yes, that'll come later.

Offline

#9 2014-04-02 17:14:42

Enio
Contributor
Registered: 2013-09-24
Posts: 175

Re: NEW snoop function able to sniff LF/HF signal.

asper wrote:

So this will be a kind of "oscilloscope" function, isn't it?

Yes, exactly. Primarily for PKD path - Maybe RAW has its use for lower frequencies, we'll see.

Offline

#10 2014-04-02 18:20:26

piwi
Contributor
Registered: 2013-06-04
Posts: 704

Re: NEW snoop function able to sniff LF/HF signal.

Enio wrote:

Thank you gaucho - just so you all see what its about - this is a snoop of a Mifare ATQA [0x0400, visible as 1(Start) 0010 0000 0(odd parity) 0000 0000 1(odd parity) End(1 bit no modulation)].

gaucho wrote:

@PIWI: for the signal on real mifare 1k tag, you can also watch my oscilloscope screenshot. All the screenshots shows the same result.

There is still a discrepancy I would like to understand with the tag response: gaucho's screenshots as well as Enio's previous screenshots show the subcarrier (modulation) at a higher voltage level than the unmodulated parts. It is just the other way round on Enio's last screenshot - and this is what I would expect from the ISO14443-2 description.

Any ideas?

If someone has two PM3s: how does a tag response with the latest code revision look like when you do hf mf sim (or hf 14a sim) on one of them and measure on TP1 at the other?

Offline

#11 2014-04-02 21:07:17

Enio
Contributor
Registered: 2013-09-24
Posts: 175

Re: NEW snoop function able to sniff LF/HF signal.

The weird thing is, the pcs->picc part seemd right on the prev. screens. As if only the answer were inverted..

Offline

#12 2014-04-03 08:35:00

gaucho
Contributor
From: France
Registered: 2010-06-15
Posts: 444
Website

Re: NEW snoop function able to sniff LF/HF signal.

it is possible that different tags implement it in a different way, because it could be possible that it is not important. Anyway when i'll have the working function I'll try on my pm3 with my tag and we will see the result. Anyway, if i well understood, this doesn't change the way how you decode the data, so it seems to me a less important practical thing, even if for study purposes this is a really important matter.

Offline

#13 2014-04-03 10:40:13

piwi
Contributor
Registered: 2013-06-04
Posts: 704

Re: NEW snoop function able to sniff LF/HF signal.

Indeed it doesn't impact receiving tag data by the PM. You are right: the FPGA implementation just looks for modulation and ignores the DC level now. In previous revisions (pre 839) it looked at the DC level only - which would mean that it would have been important with these revisions.

However, there might be readers which are more fuzzy than the PM. When simulating a tag, we should do it correctly.

Offline

#14 2014-04-03 12:35:03

gaucho
Contributor
From: France
Registered: 2010-06-15
Posts: 444
Website

Re: NEW snoop function able to sniff LF/HF signal.

piwi wrote:

However, there might be readers which are more fuzzy than the PM. When simulating a tag, we should do it correctly.

Sincerely i didn't understood how Enio made that screenshot.
It's not clear to me, how he performed the test:
Which tag did he used?
Tag was real or simulated? if simulated, how he did it?
Which reader did he used?
which command did he hitted on the PM3?
which is the sequence of operations?

Offline

#15 2014-04-03 12:55:42

Enio
Contributor
Registered: 2013-09-24
Posts: 175

Re: NEW snoop function able to sniff LF/HF signal.

gaucho wrote:
piwi wrote:

However, there might be readers which are more fuzzy than the PM. When simulating a tag, we should do it correctly.

Sincerely i didn't understood how Enio made that screenshot.
It's not clear to me, how he performed the test:
Which tag did he used?
Tag was real or simulated? if simulated, how he did it?
Which reader did he used?
which command did he hitted on the PM3?
which is the sequence of operations?

I snooped communication of a real Mifare classic 1k (MF1S50) and an nfc enabled phone running nxp TagInfo.
Command was MY latest version of hf 14b simlisten <samples to skip> (completely changed functionality completely -not related to 14b)

1. I put tag on pm3 antenna
2. I hit command
3. I quickly put phone close to card
4. data samples 40000
5. Hope i caught right window with the atqa

Ill soon put a version for yall to test, hopefully this weekend. I just need to separate it so its a nondestructive addition to current code, and add fpga configuration.

Offline

#16 2014-04-08 14:15:51

gaucho
Contributor
From: France
Registered: 2010-06-15
Posts: 444
Website

Re: NEW snoop function able to sniff LF/HF signal.

i used nxp Taginfo on the phone of the girlfriend of my friend. it's really cool since it saves skipass data, even if by modifing it we could achieve a really interesting portable rfid hack tool.

are you proceeding? do you need support? (not from me, may be from someone stronger than me)

Offline

#17 2014-04-22 11:13:03

gaucho
Contributor
From: France
Registered: 2010-06-15
Posts: 444
Website

Re: NEW snoop function able to sniff LF/HF signal.

@enio: My suggestion: do it well structured but with base functions. I mean that you could start releasing few features but working. even if you don't implement all the features.. someone could also help you to complete your work. we should never work alone.

Offline

#18 2014-04-22 21:04:54

Enio
Contributor
Registered: 2013-09-24
Posts: 175

Re: NEW snoop function able to sniff LF/HF signal.

Yes, i will. Problem was/is heavy workload but it should normalize soon.

I will release basic functionality that can be easily extended. One command with options, however itll be very easy to i.e. add an alias like lf read calling this function with correct options.

Offline

#19 2014-04-22 22:37:23

gaucho
Contributor
From: France
Registered: 2010-06-15
Posts: 444
Website

Re: NEW snoop function able to sniff LF/HF signal.

I would like to help you, cause we have another mission after this: the bluetooth interface.

i think that we need 2 commands: "hf snoop" and "lf snoop". the only difference should be that one selects the hf path and the other selects the lf path.
On my board i will remove the mux, so i will not need to make this difference, but, for backward compatibility with the actual board, it is mandatory to leave the snoop functions inside the 2 sections HF/LF.

the syntax should be this:

hf snoop <sampling frequency in Hz> <trigger level between -128 and +128> <number of samples to skip> <number of trigger to skip>

the number of samples to aquire is not a parameter because we will use all available memory

do you agree?

i started my first test (i still need to check it in practice, as you know this is my first try on arm/client development):

inside cmdhf.c:

static command_t CommandTable[] = 
{
  {"help",      CmdHelp,          1, "This help"},
  {"14a",       CmdHF14A,         1, "{ ISO14443A RFIDs... }"},
  {"14b",       CmdHF14B,         1, "{ ISO14443B RFIDs... }"},
  {"15",        CmdHF15,          1, "{ ISO15693 RFIDs... }"},
  {"epa",       CmdHFEPA,         1, "{ German Identification Card... }"},
  {"legic",     CmdHFLegic,       0, "{ LEGIC RFIDs... }"},
  {"iclass",	CmdHFiClass,      1, "{ ICLASS RFIDs... }"},
  {"mf",      	CmdHFMF,		  1, "{ MIFARE RFIDs... }"},
  {"snoop",     CmdHFsnoop,       1, "{ snoop... }"},
  {"tune",      CmdHFTune,        0, "Continuously measure HF antenna tuning"},
  {NULL, NULL, 0, NULL}

};
int CmdHFsnoop(const char *Cmd)
{
	//do something
	//for now i could start printing out a string
	PrintAndLog("# Preparing data..");
	//get these parameters from Cmd:
	//-snoop frequency
	//-trigger level
	//-samples to skip(delay) from trigger
	//-number of trigger to skip
	//Note: the used memory is all the memory available, it is not a parameter
	int samplingFrequency, triggerLevel, samplesToSkip, triggersToSkip;
	char * pEnd;
	samplingFrequency =(int)strtol (Cmd,&pEnd,10);
	triggerLevel = (int)strtol (pEnd,&pEnd,10);
	samplesToSkip = (int)strtol (pEnd,&pEnd,10);
	triggersToSkip = (int)strtol (pEnd,NULL,10);
	
	PrintAndLog("# Sampling Frequency: %dHz",samplingFrequency);
    PrintAndLog("# Trigger Level: %d",triggerLevel);
    PrintAndLog("# Samples to Skip: %d",samplesToSkip);
    PrintAndLog("# Triggers to Skip: %d",triggersToSkip);

	UsbCommand c={CMD_HF_SNOOP};
	
    c.d.asDwords[0]=samplingFrequency;   
    c.d.asDwords[1]=triggerLevel;
    c.d.asDwords[2]=samplesToSkip ;
    c.d.asDwords[3]=triggersToSkip ;




	SendCommand(&c);

	PrintAndLog("# Snoop command sent..");
	return 0;
}

Last edited by gaucho (2014-04-25 16:23:58)

Offline

#20 2014-04-23 21:34:28

gaucho
Contributor
From: France
Registered: 2010-06-15
Posts: 444
Website

Re: NEW snoop function able to sniff LF/HF signal.

REMOVED

Last edited by gaucho (2014-04-25 16:15:26)

Offline

#21 2014-05-04 21:55:51

Enio
Contributor
Registered: 2013-09-24
Posts: 175

Re: NEW snoop function able to sniff LF/HF signal.

Update: I finally found a bit time.

I went on replacing lf read into my hf snoop fpga code as theres no place for another FPGA_MAJOR_MODE and i dont want to touch other parts.

It was more complicated then i thought and im not happy with my fpga code - ill have to go over it again - but it works for now.

So now lf read and jf snoop is on one major mode and a newconfig register is used to swich between modes (lf powers antenna, hf not).

Todo: Clean up code, make better names for stuff and add sanity checks for command. Then integrate into git version (need read up about git).

Best

Offline

#22 2014-05-05 18:20:31

jonor
Contributor
Registered: 2009-09-17
Posts: 97

Re: NEW snoop function able to sniff LF/HF signal.

Very interesting your features.  I hope to try it soon.
Would have been useful 5 years ago when I bought pm3 for analize a unknow tag, here a description after 4 four years of tests.

Last edited by jonor (2014-05-05 18:24:29)

Offline

#23 2014-05-27 23:13:07

Enio
Contributor
Registered: 2013-09-24
Posts: 175

Re: NEW snoop function able to sniff LF/HF signal.

Hey all!

Im sorry for the delays, i really didnt find the time to push this forward until now. Today i finished integrating the changes i made a while ago into a fork of the pm3 git version.

This is an unstable/testing version and the code is by no means final (which you might see at the names i used for my functions..).

The repo can be found at https://github.com/EnioArda/proxmark3

To get it working (on linux with pm3 on /dev/ttyACM0) you need to

git clone https://github.com/EnioArda/proxmark3.git <directoryname>
cd <directoryname>/client
./flasher /dev/ttyACM0 ../armsrc/obj/fullimage.elf
./proxmark3  /dev/ttyACM0

The main new function is

hf snoop

which is a bit tricky to use as its not final at all when it comes to triggers when to start recording, i had quite good results with putting a mifare card on the antenna, starting TagInfo on my NFC enabled Android device, executing

hf snoop 10000 1

and putting my phone close to the card.
You should get something like this after a few tries:
yko7k.jpg


However, since in this version lf and hf snoop is put into a single fpga module, switched by configuration words, it would be really nice if you could test if lf read and functions using the old lf read fpga code still work as expected with this version.

Best, Enio

Offline

#24 2014-09-16 03:49:51

marshmellow
Contributor
From: US
Registered: 2013-06-10
Posts: 2,302

Re: NEW snoop function able to sniff LF/HF signal.

I would like to help with the lf snoop and lf read functions, but I don't have a compile environment set up.  Is anyone still working on this project?

Offline

#25 2014-12-11 06:19:04

marshmellow
Contributor
From: US
Registered: 2013-06-10
Posts: 2,302

Re: NEW snoop function able to sniff LF/HF signal.

It appears this is now in the main smile and the lf snoop works great! Thanks.!    I don't know if it is related but some are saying some lf Sim commands are functioning at incorrect rates.

Offline

#26 2014-12-11 08:13:19

Enio
Contributor
Registered: 2013-09-24
Posts: 175

Re: NEW snoop function able to sniff LF/HF signal.

This isnt in main, and it needs some adjustments to make it compatible with the new layout of fpga images. Ill soon go on improving this to a usable state.

Offline

#27 2014-12-11 15:22:11

marshmellow
Contributor
From: US
Registered: 2013-06-10
Posts: 2,302

Re: NEW snoop function able to sniff LF/HF signal.

strange...  it appears to work in asper's compiled windows client version 0.0.5 http://www.proxmark.org/forum/viewtopic.php?id=1562&p=1. must be he has gone beyond the main trunk for that compile.  I wonder if that may be where some of the comments/issues have been coming from lately.  no matter I do find the function very helpful.  Thanks!

Offline

#28 2014-12-11 21:56:46

iceman
Administrator
Registered: 2013-04-25
Posts: 9,497
Website

Re: NEW snoop function able to sniff LF/HF signal.

yup,  the "lf snoop" looks like it works.

lf snoop l
data sample 24000
data plot
data mandemod

However I still have issues with "lf em4x sim"...

Offline

#29 2015-01-10 01:56:26

asper
Contributor
Registered: 2008-08-24
Posts: 1,409

Re: NEW snoop function able to sniff LF/HF signal.

Enio any news about lf/hf snoop ?
Do you think it will be possible to save a 5-20 seconds trace in a file during sniffing or the USB is too slow for this ? I think 125KHz samples will consume less "space" than 13.56MHz... I would like to test some non-yet-supported 125KHz tags...

Offline

#30 2015-01-15 20:47:50

gaucho
Contributor
From: France
Registered: 2010-06-15
Posts: 444
Website

Re: NEW snoop function able to sniff LF/HF signal.

Hi Enio,
i'm going to ski resort and i can try to aquire HF data in order to decode exchanged traffic. I'll share aquired data.

please, tell us if we can do it and how.

i would like to find a method to aquire data, download data on the pc, and trigger a new acquisition automatically.
I could implement a sort of script on the computer (on the proxmark GUI tool) in order to receive the data.
But it is important to log the data, not to show the graph.

Offline

#31 2015-01-29 01:59:11

holiman
Contributor
Registered: 2013-05-03
Posts: 566

Re: NEW snoop function able to sniff LF/HF signal.

asper wrote:

Enio any news about lf/hf snoop ?
Do you think it will be possible to save a 5-20 seconds trace in a file during sniffing or the USB is too slow for this ? I think 125KHz samples will consume less "space" than 13.56MHz... I would like to test some non-yet-supported 125KHz tags...

See http://www.proxmark.org/forum/viewtopic … 959#p13959 for this feature

Offline

#32 2015-02-16 17:29:19

holiman
Contributor
Registered: 2013-05-03
Posts: 566

Re: NEW snoop function able to sniff LF/HF signal.

Enio wrote:

Update: I finally found a bit time.

I went on replacing lf read into my hf snoop fpga code as theres no place for another FPGA_MAJOR_MODE and i dont want to touch other parts.

It was more complicated then i thought and im not happy with my fpga code - ill have to go over it again - but it works for now.

So now lf read and jf snoop is on one major mode and a newconfig register is used to swich between modes (lf powers antenna, hf not).

@Enio, I don't know if you noticed, but a couple of weeks after you wrote this, izsh split HF and LF into separate FPGA parts https://github.com/Proxmark/proxmark3/c … bbba80c70e.

This means, as of Jun 20 2014, these modes are defined:

fpga_hf.v:

// Major modes:

//   000 --  HF reader, transmitting to tag; modulation depth selectable
//   001 --  HF reader, receiving from tag, correlating as it goes; frequency selectable
//   010 --  HF simulated tag
//   011 --  HF ISO14443-A
//   111 --  everything off

fpga_lf.v:

// Major modes:
//   000 --  LF reader (generic)
//   001 --  LF edge detect (generic)
//   010 --  LF passthrough

Which means that in HF, there are three unused major modes, and five unused in LF.

Offline

Board footer

Powered by FluxBB