Fun with Hardnested

HighPressure · 2016-09-22 21:42:34

Hey all!

I am just trying to play and test with hardnested as I got a new token which is not predictable with the other tools.

So I flashed my proxmark and gave it a try with the hardnested iceman way
looks good so far

basically what I did first was

hf mf chk *1 ? ./default_keys.dic d

which gave me
|---|----------------|---|----------------|---|
|sec|key A |res|key B |res|
|---|----------------|---|----------------|---|
|000| a0a1a2a3a4a5 | 1 | b0b1b2b3b4b5 | 1 |
|001| a0a1a2a3a4a5 | 1 | b0b1b2b3b4b5 | 1 |
|002| a0a1a2a3a4a5 | 1 | b0b1b2b3b4b5 | 1 |
|003| a0a1a2a3a4a5 | 1 | b0b1b2b3b4b5 | 1 |
|004| a0a1a2a3a4a5 | 1 | b0b1b2b3b4b5 | 1 |
|005| a0a1a2a3a4a5 | 1 | b0b1b2b3b4b5 | 1 |
|006| a0a1a2a3a4a5 | 1 | b0b1b2b3b4b5 | 1 |
|007| a0a1a2a3a4a5 | 1 | b0b1b2b3b4b5 | 1 |
|008| a0a1a2a3a4a5 | 1 | b0b1b2b3b4b5 | 1 |
|009| a0a1a2a3a4a5 | 1 | b0b1b2b3b4b5 | 1 |
|010| a0a1a2a3a4a5 | 1 | b0b1b2b3b4b5 | 1 |
|011| a0a1a2a3a4a5 | 1 | b0b1b2b3b4b5 | 1 |
|012| a0a1a2a3a4a5 | 1 | ffffffffffff | 0 |
|013| a0a1a2a3a4a5 | 1 | ffffffffffff | 0 |
|014| a0a1a2a3a4a5 | 1 | ffffffffffff | 0 |
|015| a0a1a2a3a4a5 | 1 | ffffffffffff | 0 |
|---|----------------|---|----------------|---|

So I guess that my first run with following command was correct, regarding to what Ive read in the help

hf mf hardnested 0 A a0a1a2a3a4a5 12 B b0b1b2b3b4b5 w (and later I tried it also with w s)

which gave me
--target block no: 12, target key type:B, known target key: 0xb0b1b2b3b4b5, file action: write, Slow: No, Tests: 0
Allocating memory for partial statelists...
Generating partial statelists...
Generating bitflip statelist...
Acquiring nonces...
Writing acquired nonces to binary file nonces.bin
Checking for Filter Flip Properties...
Acquired 1680 nonces ( 1660 with distinct bytes 0 and 1). Number of bytes with probability for correctly guessed Sum(a8) > 95.0%: 0
Acquired 2016 nonces ( 1988 with distinct bytes 0 and 1). Number of bytes with probability for correctly guessed Sum(a8) > 95.0%: 0
Acquired 2576 nonces ( 2533 with distinct bytes 0 and 1). Number of bytes with probability for correctly guessed Sum(a8) > 95.0%: 0
Acquired 3024 nonces ( 2958 with distinct bytes 0 and 1). Number of bytes with probability for correctly guessed Sum(a8) > 95.0%: 0
Acquired 3584 nonces ( 3482 with distinct bytes 0 and 1). Number of bytes with probability for correctly guessed Sum(a8) > 95.0%: 3
Acquired 4032 nonces ( 3903 with distinct bytes 0 and 1). Number of bytes with probability for correctly guessed Sum(a8) > 95.0%: 6
Acquired 4592 nonces ( 4428 with distinct bytes 0 and 1). Number of bytes with probability for correctly guessed Sum(a8) > 95.0%: 7
Acquired 5040 nonces ( 4843 with distinct bytes 0 and 1). Number of bytes with probability for correctly guessed Sum(a8) > 95.0%: 8
Acquired 5600 nonces ( 5359 with distinct bytes 0 and 1). Number of bytes with probability for correctly guessed Sum(a8) > 95.0%: 8
Acquired 6048 nonces ( 5760 with distinct bytes 0 and 1). Number of bytes with probability for correctly guessed Sum(a8) > 95.0%: 9
Acquired 6608 nonces ( 6277 with distinct bytes 0 and 1). Number of bytes with probability for correctly guessed Sum(a8) > 95.0%: 9
Acquired 7056 nonces ( 6674 with distinct bytes 0 and 1). Number of bytes with probability for correctly guessed Sum(a8) > 95.0%: 9
Acquired 7504 nonces ( 7069 with distinct bytes 0 and 1). Number of bytes with probability for correctly guessed Sum(a8) > 95.0%: 9
Acquired 8064 nonces ( 7573 with distinct bytes 0 and 1). Number of bytes with probability for correctly guessed Sum(a8) > 95.0%: 9
Acquired 8512 nonces ( 7968 with distinct bytes 0 and 1). Number of bytes with probability for correctly guessed Sum(a8) > 95.0%: 10
Acquired 9072 nonces ( 8455 with distinct bytes 0 and 1). Number of bytes with probability for correctly guessed Sum(a8) > 95.0%: 11
Acquired 9520 nonces ( 8831 with distinct bytes 0 and 1). Number of bytes with probability for correctly guessed Sum(a8) > 95.0%: 11
Acquired 10080 nonces ( 9310 with distinct bytes 0 and 1). Number of bytes with probability for correctly guessed Sum(a8) > 95.0%: 11
Acquired 10528 nonces ( 9700 with distinct bytes 0 and 1). Number of bytes with probability for correctly guessed Sum(a8) > 95.0%: 12
Acquired 11088 nonces (10157 with distinct bytes 0 and 1). Number of bytes with probability for correctly guessed Sum(a8) > 95.0%: 11
Acquired 11536 nonces (10529 with distinct bytes 0 and 1). Number of bytes with probability for correctly guessed Sum(a8) > 95.0%: 11
Acquired 12096 nonces (10998 with distinct bytes 0 and 1). Number of bytes with probability for correctly guessed Sum(a8) > 95.0%: 11
Acquired 12544 nonces (11376 with distinct bytes 0 and 1). Number of bytes with probability for correctly guessed Sum(a8) > 95.0%: 12
Acquired a total of 12768 nonces in 11.6 seconds (65855 nonces/minute)
Number of first bytes with confidence > 95.0%: 13
Generating crypto1 state candidates...
Number of possible keys with Sum(a0) = 136: 16937635385344 (2^43.9)
Reducing Partial Statelists (p,q) = (6,10) with lengths 181736, 185062
Reducing Partial Statelists (p,q) = (10,6) with lengths 182032, 178706
Number of remaining possible keys: 5697475782 (2^32.4)
Time for generating key candidates list: 1 seconds
Looking for known target key in remaining key space...
Key Found after testing 357136320 (2^28.4) out of 5697475782 (2^32.4) keys.

... ok cool but where is the key? in my first test I ran it without giving it key B and it said success and presented me the B Key given as known key

ahh... it was maybe because I need to run

hf mf hardnested r b0b1b2b3b4b5
--target block no: 0, target key type:A, known target key: 0xb0b1b2b3b4b5, file action: read, Slow: No, Tests: 0
Allocating memory for partial statelists...
Generating partial statelists...
Generating bitflip statelist...
Reading nonces from file nonces.bin...
Read 9968 nonces from file. cuid=********, Block=12, Keytype=B
Checking for Filter Flip Properties...
Number of first bytes with confidence > 95.0%: 13
Generating crypto1 state candidates...
Number of possible keys with Sum(a0) = 136: 16937635385344 (2^43.9)
Reducing Partial Statelists (p,q) = (6,10) with lengths 181736, 185062
Reducing Partial Statelists (p,q) = (10,6) with lengths 182032, 178706
Number of remaining possible keys: 5549409296 (2^32.4)
Time for generating key candidates list: 2 seconds
Looking for known target key in remaining key space...
Key Found after testing 249283122 (2^27.9) out of 5549409296 (2^32.4) keys.

same result?

so maybe without the key...

hf mf hardnested r
--target block no: 0, target key type:A, known target key: 0x000000000000 (not set), file action: read, Slow: No, Tests: 0
Allocating memory for partial statelists...
Generating partial statelists...
Generating bitflip statelist...
Reading nonces from file nonces.bin...
Read 9968 nonces from file. cuid=0b8ebafc, Block=12, Keytype=B
Checking for Filter Flip Properties...
Number of first bytes with confidence > 95.0%: 13
Generating crypto1 state candidates...
Number of possible keys with Sum(a0) = 136: 16937635385344 (2^43.9)
Reducing Partial Statelists (p,q) = (6,10) with lengths 181736, 185062
Reducing Partial Statelists (p,q) = (10,6) with lengths 182032, 178706
Number of remaining possible keys: 5549409296 (2^32.4)
Time for generating key candidates list: 2 seconds
Brute force phase starting.
Using 128-bit bitslices
Bitslicing best_first_byte^uid[3] (rollback byte): c0...
Bitslicing nonces...
Starting 4 cracking threads to search 8 buckets containing a total of 5549409296 states...
........ICE 23 seconds
Fail! Tested 1254442000 states, in 23 seconds

guess so far I ran everything correct, but just wasnt lucky?
so can I somehow modify how long it is running and searching or any other hints?

especially @ iceman
and at the same thanks for the cool new feature!

Last edited by HighPressure (2016-09-24 23:29:01)

HighPressure · 2016-09-22 21:57:37

btw funny, no matter if proxmark or iceman build:

....
Found valid key:[b0b1b2b3b4b5]
--sector:10, block: 43, key type:B, key count: 2
Found valid key:[b0b1b2b3b4b5]
--sector:11, block: 47, key type:B, key count: 2
Found valid key:[b0b1b2b3b4b5]
--sector:12, block: 51, key type:B, key count: 2
--sector:13, block: 55, key type:B, key count: 2
--sector:14, block: 59, key type:B, key count: 2
--sector:15, block: 63, key type:B, key count: 2

proxmark3> hf mf chk 12 B a0a1a2a3a4a5 b0b1b2b3b4b5
chk key[ 0] a0a1a2a3a4a5
chk key[ 1] b0b1b2b3b4b5
--sector: 0, block: 12, key type:B, key count: 2
Found valid key:[b0b1b2b3b4b5]

proxmark3> hf mf chk 13 B a0a1a2a3a4a5 b0b1b2b3b4b5
chk key[ 0] a0a1a2a3a4a5
chk key[ 1] b0b1b2b3b4b5
--sector: 0, block: 13, key type:B, key count: 2
Found valid key:[b0b1b2b3b4b5]

iceman · 2016-09-22 23:50:19

You missunderstand the parameters to the "hf mf hard" command.
As mentioned in most hardnested posts, the output shows sectors but the commands takes blocks.
so if you are seeking sector 12 (but zerobased index)
and if you give the targetkey it only tries to verify it, which you see "Key found ..." message

--> hf mf hardnested 0 A a0a1a2a3a4a5 52 B

piwi · 2016-09-23 17:45:26

So he is targeting block 12 instead of the intended sector 12. But the brute force shouldn't fail because we know that the known key is there.

?

iceman · 2016-09-23 17:51:41

Its you who wrote this stuff Piwi, the BF solver doesnt attack a known key, then it defaults back to your test imp.
hint: "Looking for known target key in remaining key space..."

When are you releasing your updated implementation? I kind of miss your corrections of my code.

[edit] remove erronous statement about 'r' parameter.

piwi · 2016-09-23 19:42:29

It doesn't matter if you run it with or without r. If you add a known key it will just check if the key is in the remaining key space. If not, it is up to the brute force phase to find the key.

Next release will be finished when it is finished.

iceman · 2016-09-23 20:11:49

So the "r" parameter loads the nonces file, with all data you called it with ie targetkey, targetblock, and @OP's execution failed.

Try again to get new nonces? It could be those "hard" nonces which Piwi mentioned earlier.

@Piwi, take your time there is no rush.

piwi · 2016-09-23 20:39:15

He gets "key found" when adding the known key "b0b1b2b3b4b5" as additional parameter. It fails when he tries to brute force (without additional Parameter). Same nonces from file. I.e. the brute force fails to find the key, although it is in the remaining key space. I.e. there seems to be a bug in brute force.

And yes, the nonces.bin file contains target block, uid and target key (A or B).

iceman · 2016-09-23 21:44:41

You should ask @Aczid about this. The BF solver is his fantastic solution and is better suited to answer questions.
If we ruled out that the other test is working of course.

gator96100 · 2016-09-24 22:37:35

@HighPressure unfortunately I can’t message you directly. I know exactly what tags you are analysing. If you are interested in helping me find the algorithm for the key generation please message me.

iceman · 2016-09-24 22:46:48

That is impressive, since there is no details whats so ever of the tag besides its a s50 /1k new prng tag with default keys on...

HighPressure · 2016-09-24 23:28:19

gator96100 wrote:

@HighPressure unfortunately I can’t message you directly. I know exactly what tags you are analysing. If you are interested in helping me find the algorithm for the key generation please message me.

So having a look at you introduction, I guess you are then running the firefart website?
If so I read your article earlier to this.
Did you recognize it because of the sectors or what was the reason for recognition? I assume it was not the uid of the card, which I forgot to remove in the output earlier (cuid)?

I got some background knowledge of how programming and setup of the system works - so with this yes, I guess I could help.
At the same time we are looking into improvements for the security system - so its more a fun project at the moment and nothing official yet.
I'll message you with more details, which would offtopic this one here.

@Iceman - you got me with your email.. so I turned on my machine right now.

I checked the error with block vs sector and yes, I missread the details in the help
but no matter, also with block 44 or block 45 the result is that he found b0b1b2b3b4b5 which also is confirmed with a hf mf chk on a single sector as stated earlier. I'll send the nounces in a second

same result with following commands
hf mf hardnested 0 A a0a1a2a3a4a5 44 B w
hf mf hardnested 0 B b0b1b2b3b4b5 44 B w
hf mf hardnested 0 B b0b1b2b3b4b5 45 B w

its always
Found key: b0b1b2b3b4b5

gator96100 · 2016-09-25 01:50:18

HighPressure wrote:

gator96100 wrote:
@HighPressure unfortunately I can’t message you directly. I know exactly what tags you are analysing. If you are interested in helping me find the algorithm for the key generation please message me.
So having a look at you introduction, I guess you are then running the firefart website?
If so I read your article earlier to this.
Did you recognize it because of the sectors or what was the reason for recognition? I assume it was not the uid of the card, which I forgot to remove in the output earlier (cuid)?
I got some background knowledge of how programming and setup of the system works - so with this yes, I guess I could help.
At the same time we are looking into improvements for the security system - so its more a fun project at the moment and nothing official yet.
I'll message you with more details, which would offtopic this one here.
@Iceman - you got me with your email.. so I turned on my machine right now.
I checked the error with block vs sector and yes, I missread the details in the help
but no matter, also with block 44 or block 45 the result is that he found b0b1b2b3b4b5 which also is confirmed with a hf mf chk on a single sector as stated earlier. I'll send the nounces in a second
same result with following commands
hf mf hardnested 0 A a0a1a2a3a4a5 44 B w
hf mf hardnested 0 B b0b1b2b3b4b5 44 B w
hf mf hardnested 0 B b0b1b2b3b4b5 45 B w
its always
Found key: b0b1b2b3b4b5

I'm not the owner of the firefart website, but I did read the article.
The combination of known keys and missing b keys from sector 12-15 was enough to assume that you were trying to analyse the nfc system of a popular Austrian company.
Also using iceman's fork I did manage to get the b keys (using hf mf hardnested 0 A a0a1a2a3a4a5 48 B) on my tags.

Last edited by gator96100 (2016-09-25 02:06:59)

iceman · 2016-09-25 06:55:38

If you attack block 44,45 which still is in the same sector, so you should most definitly get the same key.

OP, thanks for the email.

-target:   sector:12, block: 51, key B
hf mf hardnested 0 A a0a1a2a3a4a5  51 B

-target:   sector:13, block: 55, key B
hf mf hardnested 0 A a0a1a2a3a4a5  55 B

-target:   sector:14, block: 59, key B
hf mf hardnested 0 A a0a1a2a3a4a5  59 B

-target:   sector:15, block: 63, key B
hf mf hardnested 0 A a0a1a2a3a4a5  63 B

HighPressure · 2016-09-25 08:46:51

I knew there was a reason why I was planning to send you details tomorrow (today) lol
Focused on sector 11 instead 12.
So 48 should have brought success as gator had

Yes, gator you are right its the famous one
Btw check my other posts.. Got some other interesting cards to play with.
We should meet if youd like to. Could be fun. Got some other funny gadgets like the hackrf too.

iceman · 2016-09-25 09:14:14

and I would need to get a noncefile from when it fails but checking say it found it. Like your first post..

HighPressure · 2016-09-25 21:03:32

btw, I wanted to mention,... today I had the chacne to check a token of a concurrent of the company token I was looking at.
Same layout as in my first post,.. except that they moved everything to sector 11 + use the same sectors as above.

I did shoot at 44 B as its sector 11, with hardnested... it ran and ran and ran.. like 10 mins and was working strong.
As my mate had his token for long time now and I had no time left, I thought to myself "hey hm lets give it a try with hf mf nested anyway" and badabing like in no time it had the keys hardnested was looking for waaay longer time already.

So lesson learned: first check the known methods then use hardnested, if not prectable

funny thing aside: company 1 has no relation with company 2 and the data in the dumps is exactly the same with company 3.
All of them use U-Tag Token´s based on mifare.
So it seems that there is a distributor for these kind of systems for vending machines and its not a self built solution
had no time yet to compare the keys or to run hardnested as gator described. would be funny if its even the same key.

wouldnt be the first time to see... I checked a door system where the vendor name is the key to he access permissions lol (ascii company name > hex = key)

piwi · 2016-09-26 06:36:32

HighPressure wrote:

"hey hm lets give it a try with hf mf nested anyway" and badabing like in no time it had the keys hardnested was looking for waaay longer time already.
So lesson learned: first check the known methods then use hardnested, if not prectable

Yes, that is absolutely correct. hf mf hardnested needs nonces with some entropy. The broken PRNG of old cards doesn't generate enough entropy.

HighPressure · 2016-09-26 20:37:34

thanks for the explanation

HighPressure · 2016-09-26 21:55:51

something else.. searching keys for sector 15 lasted 35 sec while sector 14 was done in 15 sec
sector 13 is searching like for ever.. skipped it in the meantime and tried first sector 12
was running also longer than the others.. no keys found,
reran it with 0 B b0b1b2b3b4b5 instead of the 0 A ... same.. tried different block... same.. tried to crosscheck an already found key from sector 14 to prove its working - found the key of sector 14
deleted the existing nonces.bin so I got a new one to show you (iceman) as you asked for.... ran it again and suddenly it found the key?

was it just luck? was it messed up with the already large grown nonce file?
I just ran the command from the history, so it cant be a typo and i did not touch the token
and hey.. I ran it 4 or 5 times over and over again.

print after success:
Acquired a total of 33488 nonces in 47.6 seconds (42230 nonces/minute)
Number of first bytes with confidence > 95.0%: 13
Generating crypto1 state candidates...
Number of possible keys with Sum(a0) = 256: 8151629441024 (2^42.9)
Reducing Partial Statelists (p,q) = (0,16) with lengths 126756, 126634
Reducing Partial Statelists (p,q) = (16,0) with lengths 125600, 125722
Number of remaining possible keys: 12444082232 (2^33.5)
Time for generating key candidates list: 2 seconds
Brute force phase starting.
Using 128-bit bitslices
Bitslicing best_first_byte^uid[3] (rollback byte): d5...
Bitslicing nonces...
Starting 4 cracking threads to search 8 buckets containing a total of 12444082232 states...
..Success! Tested 3798255264 states, found 1 keys after 29 seconds

for the failed run it said for example
Acquired a total of 29456 nonces in 40.3 seconds (43825 nonces/minute)
Number of first bytes with confidence > 95.0%: 13
Generating crypto1 state candidates...
Number of possible keys with Sum(a0) = 256: 8151629441024 (2^42.9)
Reducing Partial Statelists (p,q) = (0,16) with lengths 126756, 126634
Reducing Partial Statelists (p,q) = (16,0) with lengths 125600, 125722
Number of remaining possible keys: 4263614264 (2^32.0)
Time for generating key candidates list: 2 seconds
Brute force phase starting.
Using 128-bit bitslices
Bitslicing best_first_byte^uid[3] (rollback byte): 91...
Bitslicing nonces...
Starting 4 cracking threads to search 8 buckets containing a total of 4263614264 states...
........Fail! Tested 4263614264 states, in 15 seconds

rerunning sector 13 where it was collecting 87584 nonces in 106 seconds and checking now 1090268382168 states
it found the key then after 1580 seconds for this sector too

btw: none of these keys was the same like from the other company, while data layout is the same

piwi · 2016-09-27 20:23:26

HighPressure wrote:

something else.. searching keys for sector 15 lasted 35 sec while sector 14 was done in 15 sec
sector 13 is searching like for ever.. skipped it in the meantime and tried first sector 12
was running also longer than the others..

This has to be expected. Remember that this attack has only unknown random numbers (the nonces) encrypted with an unknown key as its input. Depending on the key and the nonces the attack can exclude more or less keys. The remaining key space may be smaller or bigger.

HighPressure wrote:

no keys found,

Unfortunately this has to be expected as well. The attack must make some guesses - which can be wrong. With the current settings, you need to expect 25 to 30% failures. Plus some failures due to bugs in the implementation.

HighPressure wrote:

reran it with 0 B b0b1b2b3b4b5 instead of the 0 A ... same.. tried different block... same..

Doesn't help. The first key is only used for the first authentication, in order to be able to start a (nested) authentication against the target block - which will result in an encrypted nonce delivered by the card. So it doesn't matter which block and key you are using for the first authentication

HighPressure wrote:

tried to crosscheck an already found key from sector 14 to prove its working - found the key of sector 14

Doesn't help too much. If you add a known target key, the attack will only check if this key is among the (usual several billiion) possible key candidates. If this key is found, it only tells us that this key hasn't been eliminated from the candidate key set. It can be a wrong key and it can be the correct key. This is a debugging feature only.

HighPressure wrote:

deleted the existing nonces.bin so I got a new one to show you (iceman) as you asked for....

Not necessary. The nonces.bin is overwritten every time you use the w option.

HighPressure wrote:

ran it again and suddenly it found the key? was it just luck?

Yes.

HighPressure wrote:

was it messed up with the already large grown nonce file?

No, the nonces.bin file doesn't grow. See above.

HighPressure wrote:

btw: none of these keys was the same like from the other company, while data layout is the same

If they take security somewhat seriously, they would use key diversification, i.e. each card has different keys.

gator96100 · 2016-09-27 22:28:43

piwi wrote:

HighPressure wrote:
btw: none of these keys was the same like from the other company, while data layout is the same
If they take security somewhat seriously, they would use key diversification, i.e. each card has different keys.

I have made dumps from about 20 different cards, the keys seems to be random to me, but they aren't.
The keys are generated with the uid and some values from block 48.

Last edited by gator96100 (2016-09-27 22:29:30)

piwi · 2016-09-28 06:49:51

Are you sure? Everything (UID and block 48) would be easily available to an attacker - except the algorithm for the time being. That would be another bad example of security by obscurity.

iceman · 2016-09-28 08:58:29

If you post samples, we can start figuring out the key diversification algo. Always fun

gator96100 · 2016-09-28 20:32:21

I'm pretty sure it's only UID and block 48 for key generation(maybe some values from sector 0, but they are the same on all cards). I did a sniff once and it seems that before accessing block 50 it access block 48(which is accessible with the a key) and then access block 50 with the b key. Unfortunately the NFC system was removed in our school in May. A “new” NFC system should be installed next week(probably only s50 with new prng instead of s50 with old prng as it was before ). I will wait for the new system before I post any dumps.

HighPressure · 2016-09-28 20:52:40

Did you check if its related to the serial number on the rear?
Every customer has a customer number. Maybe its a mix of the no and uid
Had no chance to check other tokens yet, got only one test token per company

gator96100 · 2016-09-28 21:29:54

HighPressure wrote:

Did you check if its related to the serial number on the rear?
Every customer has a customer number. Maybe its a mix of the no and uid
Had no chance to check other tokens yet, got only one test token per company

Thanks for the idea. They serial number is indeed stored in block 48 and it's the only difference in block 48 from card to card.
Never thought of the serial number. Now there is 1 unknown variable less.

iceman · 2016-09-28 21:34:00

I suggest you make a new thread with all details about your tries into this vending system.

HighPressure · 2016-09-28 21:39:26

I'll have the chance to see a programmer for these devices / cards
Maybe well know more then

Will start a thread if gator hasnt until then

Wummi · 2016-11-05 10:11:19

hey guys (HighPressure and gator96100)

i'm actualling working on the same cards please contact me at rfid [ä] wummi.at

Proxmark3 community

Announcement

#1 2016-09-22 21:42:34

Fun with Hardnested

#2 2016-09-22 21:57:37

Re: Fun with Hardnested

#3 2016-09-22 23:50:19

Re: Fun with Hardnested

#4 2016-09-23 17:45:26

Re: Fun with Hardnested

#5 2016-09-23 17:51:41

Re: Fun with Hardnested

#6 2016-09-23 19:42:29

Re: Fun with Hardnested

#7 2016-09-23 20:11:49

Re: Fun with Hardnested

#8 2016-09-23 20:39:15

Re: Fun with Hardnested

#9 2016-09-23 21:44:41

Re: Fun with Hardnested

#10 2016-09-24 22:37:35

Re: Fun with Hardnested

#11 2016-09-24 22:46:48

Re: Fun with Hardnested

#12 2016-09-24 23:28:19

Re: Fun with Hardnested

#13 2016-09-25 01:50:18

Re: Fun with Hardnested

#14 2016-09-25 06:55:38

Re: Fun with Hardnested

#15 2016-09-25 08:46:51

Re: Fun with Hardnested

#16 2016-09-25 09:14:14

Re: Fun with Hardnested

#17 2016-09-25 21:03:32

Re: Fun with Hardnested

#18 2016-09-26 06:36:32

Re: Fun with Hardnested

#19 2016-09-26 20:37:34

Re: Fun with Hardnested

#20 2016-09-26 21:55:51

Re: Fun with Hardnested

#21 2016-09-27 20:23:26

Re: Fun with Hardnested

#22 2016-09-27 22:28:43

Re: Fun with Hardnested

#23 2016-09-28 06:49:51

Re: Fun with Hardnested

#24 2016-09-28 08:58:29

Re: Fun with Hardnested

#25 2016-09-28 20:32:21

Re: Fun with Hardnested

#26 2016-09-28 20:52:40

Re: Fun with Hardnested

#27 2016-09-28 21:29:54

Re: Fun with Hardnested

#28 2016-09-28 21:34:00

Re: Fun with Hardnested

#29 2016-09-28 21:39:26

Re: Fun with Hardnested

#30 2016-11-05 10:11:19

Re: Fun with Hardnested

Board footer