unbelievr

The paper for it is open. The technique isn't really hiding information in the text itself, but by forcing some of the rolls to follow a specific pattern. LLMs work by estimating the most likely next token, so there's sometimes a list of possible candidates that would all work in the text (e.g. synonyms). At low "temperature", the output is a bit more deterministic and otherwise it's a weighted dice roll of which token/word to pick. An LLM can loop over existing text and figure out if the output matches something it would do, similar to checking chess moves against the best computed move for detecting cheating. But the LLM purposefully creates a pattern of alternating weighted rolls that are highly unlikely to appear in normal text, and that becomes the watermarking.

The upside is that this has very low false positive detection rate, but the downsides are many. It only works on longer pieces of text. The system is fragile, and small edits (or rewrites by a local model) can fool the detection. Only the owner of the model is able to re-run inference at this level, so data must be sent to them for evaluation. And sometimes the token output is basically 100% deterministic because the input asks for the straight answer to a fact, or to recite a quote verbatim. That leaves no room for watermarking at all, unless the model is able to lie.

Here it's typical that a thesis will be printed as a book, and it's that book that will be evaluated. For PhDs, there's a doctoral defence in front of a committee, peers and other interested parties and they're all given the book.

Usually the process for ordering books is that you send them a PDF with embedded fonts inside it, and it's made at the university's printing house. They will handle distribution etc. So you really, really want it to look right at the first go.

There's been some progress the past few years now where you get to preview the book somewhat, but one surefire way to get it right is to use something like LaTeX. It used to be one of few WYSIWYG solutions out there. And it used to be really hard to do certain required things in e.g. Word. For instance skipping some page numbering and doing others in roman numerals etc.

For the first few days while the game was live (and a huge chunk of the beta period), the game worked as if you had a map. You could see Pokémon quite far away, and it would tell you how far away it was with a resolution of 20m. Once this got taken out of the game, and replaced with nothing, people who depended on that feature kept wanting it back so much that they re-made it.

On release day, the app itself was great. It had a warmer/colder system with 0-3 paw prints to track down the Pokémons in your vicinity. Hunting down things you missed was a game in itself. When the servers weren't dying, the game was quite responsive too.

Fast forward a week, and the warmer/colder system is broken. All the Pokémons are always 3 steps away, which means somewhere within 1km radius. And you have 15 minutes to find that one you're missing. You can still see them from 100 meters away, and the app is quite responsive when you get close to them. The downtime is unbearable at times, and people are losing items they paid real money for due to this.

Then we fast forward two weeks. People have started reverse-engineering the internal API and are using it to create maps over nearby Pokémons. The brokenness of the tracking system is acknowledged at some convention (not publicly on their site), but no promises are made on fixing it. Niantic starts sending out C&Ds to projects using their APIs, trying to remove bots and tracking websites. Despite their own tracker being broken. The app is now limited to communicating once per 10 seconds, and you can only see Pokémons 70m around you.

After successfully hiring a PR manager, Niantic breaks their deafening silence and tells us that the tracking system will not be fixed. They will replace it with something better. A new app rolls out, now with request signing to combat tracking websites. This takes about 5 days to crack before business returns to usual. People really want to be able to track their Pokémons, and having no ways to do so put a lot of people off. Closing Pokevision made many of my friends quit, because to them, Niantic didn't share their concerns at all.

Finally, the tracking system is replaced with a new one. You can now detect nearby Pokémons up to 200m (vs 1000m before). You still need to get within 70m of them to actually see them though. Niantic also activate an extra tracking system in certain American states, as a beta test. This has been active for about two weeks now without hitting the rest of the player base. Unfortunately, it is based on Pokestops, which are user-submitted landmarks from their previous game, Ingress. A lot of places do not have these at all, or extremely few. This makes the game basically unplayable in rural areas, where you'll rapidly run out of items or never find anything interesting.

For me, personally, I feel this game has great potential, but I really miss more openness from Niantic. What are their plans for the future? Which concerns are they acknowledging? Which are intentional features of the game, and thus ignored? I think this game basically blew up in their faces, and they weren't ready to handle the interest. It's sad that they let this chance go, because I think it will be extremely hard for them to redeem themselves after this.

There are quite a lot of guides out there on sites like hackforums I reckon. The search keywords are "aircrack-ng WPA".

In short terms, you need to sniff the 4-way handshake between a legitimate client and the AP it connects to. This can sometimes be forced by spoofing a "deauth" (disconnect) packet from the client, but requires support in the chipset for your wlan-card. (Injection and monitor mode).

Once you have the handshake, your options are either aircrack-ng, hashcat or other password cracking tools. Some of these have a crazy amount of options and possibilities for cracking, and getting to know them can increase your success rate by a lot.

However, the easiest way these days is to exploit WPS in the AP. Look up Reaver and Pixiewps.

The latest iterations on the security front utilizes ECDH for key exchange (LE secure connections) and seems fairly robust. The legacy pairing implementation is vulnerable to mitm during the very first bonding, except in the case where the devices use out-of-band data like NFC. Neither Android or iOS opted to ever implement OOB, so that made security more difficult. It required us to tell our customers to reduce output power during bonding, so that the devices had to be close enough to avoid sniffing.

I felt that for the Low Energy part, the security concerns in this article were quite outdated. None of the listed attacks are applicable for LE.

Other than that, I think this gave a very good introduction to the protocol on all layers. I think the future for Bluetooth will be its ability to hook up lots of cheap sensors to a hub (with internet access, optionally) that can work for years without changing the battery. Unfortunately, the companies that already have a market share in e.g audio are trying to stall future advances in the LE front. Others are trying to basically reimplement BR/EDR in LE, thinking it will still stay "low energy".

Does this support the thumb (2) instruction set as well, or only ARM mode? We are primarily using ARM on Cortex M-devices that only run in thumb mode, but something like this tool would be very valuable for learning!

I have wanted to apply some amount of fuzzing for embedded development, but have not yet stumbled over any tools or strategies for this. Is there anyone who have some experience with this?

More specifically, I want to test against a stack with an API written in C, but the problem is that it is only accessible through code. Code that needs to be flashed to physical hardware before running. A crash in the stack leads to some trigger that can give output, so it's easy to identify a crash. For now, I have made a serialization layer for the API functions, but feel like any fuzzing methodologies would mainly test the serialization instead of the underlying stack.

Is there any tools out there that can do this, or what AFL-fuzz does but on ARM Cortex M running with a debugger?

Yes, definitely. XPrivacy can fake data, so that works even better than AppOps, but is harder to set up.

I also miss the possibility to give slightly fuzzed/offset values for certain things, like GPS granularity (Do you need to know my exact location, or just my country?) There's however an eternal struggle between the API devs wanting to make the permission system simpler, and the APP devs wanting it smarter and more refined.

A feature that could disable certain permissions for a single app was briefly introduced in an earlier version of 4.3.x, but was removed again shortly thereafter. Apparantly, most apps were written to expect permissions to be granted and crashed pretty hard if they didn't get their way.

It is available for rooted phones running Stock Android through the Xposed framework. There it is called "AppOpsXposed".

Going with your suggestion, the amount of DBs must be huge. The most prominent additions after the + sign (ignoring just single numbers) are:

- Bioware (54)

- Bravenet (19)

- Bryce/daz3d/daz (244)

- Eharmony (64)

- Filedropper/fd/etc. (113)

- Freebie/Freebiejeebies (64)

- Friendster (65)

- Hon (42)

- Policeauctions (28)

- Savage/Savage2 (116)

- Xtube/porn (200ish)