ewpratten

I’m doing that (similar scale and same language) with a base model M4 mini. Works great. Anything more is overkill imo.

I completely agree with you. In my opinion, using GPS as Stratum 0 feels like a cheat. I do hope to some day (definitely not any time soon) own an atomic clock of some kind though.

Regarding PPS, the L76B does this cheaty thing where it actually sends the PPS signal over UART. They provide a calculation to go from “Time of first byte” to a regular PPS signal on the receiving side.

Regarding the Cloudflare part of this, I’d recommend taking a look at “Authenticated Origin Pulls”. It lets you perform your validation at the TLS layer instead of doing it with IP ACLs if that interests you.

You should probably be looking at the Cargo.toml file(s) (for direct dependencies at least) instead of the lock file as the lock file will include dependencies used for dev/testing.

It’s automated in the kind of way that makes a lot of sense to people familiar with the internal HR systems.

Think of it like a subset of MIFARE.

In a simple sense, NTAG cards can do NFC things, but MIFARE can do lots more (access control for example)..and also NFC things..somewhat.

Magic mifare refers to special cards that let you bypass the write-lock of genuine mifare cards. These are mostly used for cloning keys (either for red-team pentesting or for people who want a copy of an office key for whatever reason)

All my knowledge is trial & error.

I've found the people over in the DT forum are pretty helpful with the cloning and usage aspect of things: https://forum.dangerousthings.com

Additionally, Iceman's Discord people has tons of smart people: https://discord.com/invite/iceman

Are you sure? The NFC app for iPhone can always read tags. Its specifically getting phones without the app to read them.

Try wiping, then writing a URL from Android.

Then just tap to the iPhone and see if Safari opens or not. It shouldn't

There's lots of info about the NDEF "packet" format online.

I used this page as reference when I was putting together the "magic bytes" in the final section of the blog post: https://www.oreilly.com/library/view/beginning-nfc/978144932...

Thank you very much!

Something's clearly up there. You can see that even IOS and Android disagree with each other on what NDEF should look like by a few bytes. Very interesting.

Wipe the card.

Make a dump after doing "hf mf ndefformat".

Then make a dump after writing a payload from an iPhone. (since iPhone seems to want ndefformat anyways)

Then wipe again and make a dump after writing from Android.

Ya, looks like the iPhone is tinkering with the NDEF message itself.

If my Android phone wasn't dead, I'd love to compare an iPhone's write against the Android NFC Tools app's write.

If anyone else has an iPhone, an Android phone, and a Proxmark, I'd be interested in seeing a three-way diff between them all.

EDIT: I'm going to try to cross-post to the DT forum to see if anyone has ideas.

There's approx 4 generations of "Magic".

Gen 1, 1a, 3 and 4 all use special commands to unlock and edit block 0.

Gen 2 treats block 0 as always being r/w. This allows Android phones to directly write to it (but also makes it possible to lock the card).

In terms of pm3 commands, "auto" tries everything. You might also want to use "lf search" or "hf search" to only try one of your antennas and not the other.

The actual Magic part isn't really important here, since my phone doesn't even care about block 0. It just makes it easier to read and wipe the card when you have the extra command set at your disposal.

Proxmark's "auto" command should get you most of the way to knowing. Then check if any of the "hf mf c*" commands work on it (in which case, you have a gen1a magic card)

HN formatting is going to do bad things here..

Here's the first 6 blocks of the card after I ran through the instructions of the post, then a ndefformat-only card (that never touched an iphone).

[=] 0 | 0 | 00 56 78 BB 95 08 04 00 02 B2 1E 24 23 27 1E 1D | .Vx........$#'.. [=] | 1 | 14 01 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 | ...�.�.�.�.�.�.� [=] | 2 | 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 | .�.�.�.�.�.�.�.� [=] | 3 | A0 A1 A2 A3 A4 A5 78 77 88 C1 89 EC A9 7F 8C 2A | ......xw.......* [=] 1 | 4 | 00 00 03 12 D1 01 0E 55 04 65 77 70 72 61 74 74 | ....�..U.ewpratt [=] | 5 | 65 6E 2E 63 6F 6D FE 00 00 00 00 00 00 00 00 00 | en.com�.........

[=] 0 | 0 | 00 56 78 BB 95 08 04 00 02 B2 1E 24 23 27 1E 1D | .Vx........$#'.. [=] | 1 | 14 01 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 | ...�.�.�.�.�.�.� [=] | 2 | 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 03 E1 | .�.�.�.�.�.�.�.� [=] | 3 | A0 A1 A2 A3 A4 A5 78 77 88 C1 89 EC A9 7F 8C 2A | ......xw.......* [=] 1 | 4 | 03 00 FE 00 00 00 00 00 00 00 00 00 00 00 00 00 | ..�............. [=] | 5 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................

Hm, its definitely blocks 0-2. All remaining blocks after that are identical.

Going to look further at the actual data in the first 3 blocks momentarily.

My quick eye-skim didn't see much, but I'll do a byte-for-byte diff. I imagine its a difference in the NDEF headers? (but even that doesn't make sense, since I wrote the headers again from the pm3)

(glances at chip on my desk)

..yes.

Hopefully getting that installed later this week :)

Ya, I have no clue tbh.

This is one of those cases where I know I really should investigate further, but I'm taking this one step at a time. Perhaps digging in to the "why" will become a follow-up post

Ah, we did the under-the-table thing with NFC stickers in school! Love rickrolling a well-placed phone on a classroom desk lol.

I'm personally not a huge fan of needing to use NFC tags in the real world (parking meters use them for payment around here), but I do like creating tags.