Home on Mal Breaks Things

Retrieving your Google Services Framework ID

mal@sec.gd (mal) — Thu, 21 Aug 2025 04:00:00 +0000

My partner and I use GrapheneOS on our phones. Google is as supportive of this as you would imagine, so this causes some problems, like failing SafetyNet CTS preventing many bank and DRM’d media apps from working. She recently tried to use an app that seemed to refuse to launch because Graphene isn’t Play Protect Certified.

Google created a page to allow users of custom ROMs to register their Google Services Framework ID to bypass Play Protect certification requirements, presumably after some antitrust threats. There are reports that it originally accepted an IMEI as well, but that doesn’t seem to be the case anymore, even when padding it with zeroes.

So it seems like in theory we’ll be able to avoid some compatibility complaints on the Play Store and in apps by registering our devices with the GSF IDs - but first we need to find them.

Note that while the Google Services Framework ID (GSF ID) is sometimes called android_id, it is not the same as Settings.Secure.ANDROID_ID (adb shell settings get secure android_id) or the advertising IDs. The GSF ID also changes when the device is wiped, and may be different for each user.

Official Method

On the device registration page Google recommends running:

adb root
adb shell 'sqlite3 /data/user/$(cmd activity get-current-user)/*/*/gservices.db \
    "select * from main where name = \"android_id\";"'

This requires a debug build, which won’t help me on Graphene.

With su

The obvious workaround is to use su to elevate to root, which is also not helpful on Graphene, but may be for you. I also didn’t have sqlite3 on my test device, so I did that part on the computer, and also fixed the quotes in their query.

pc$ adb shell
phone$ su
phone# cp /data/user/$(cmd activity get-current-user)/*/*/gservices.db /sdcard/
phone# exit
phone$ exit
pc$ adb pull /sdcard/gservices.db
pc$ sqlite3 gservices.db "select * from main where name = 'android_id';"

The Internet’s Suggestions

For a long time, apps could retrieve the GSF ID. This was obviously a privacy nightmare, so they can’t anymore, and all apps that don’t use root are useless on Android 14ish and newer.

Without root

Since this ID is used to identify your device to Google, I suspected it would end up reused in some web interface. There were a few suspicious 16-character hex strings and long decimal numbers near my phone’s name in the source of the devices page of the Play Store, but none were my GSF ID. A different 21-digit decimal number shows up when selecting a device to install an app to, also not the needed ID. A base64 string shows up in other places, also unrelated.

Interestingly, I ended up finding it not on the Play Store but from the “Find Hub” device list.

Disclaimer: While the ID retrieved this way does match the one from gservices.db, I haven’t actually gotten a GrapheneOS phone to show up as certified. There may be requirements other than device registration.

To find yours:

Load the Find Hub
In Chrome, press Ctrl+Shift+J (Mac: Cmd+Opt+J), or in Firefox, Ctrl+Shift+K (Mac: Cmd+Opt+K)
If prompted, type allow pasting. Don’t ignore the warning: Putting untrusted code here could give someone control of your Google account and more.

Now that you’ve ignored the warning, paste this incomprehensible mess into the console and press enter:

window.AF_initDataKeys.map(k=>document.querySelector("script."+CSS.escape(k))).flatMap(s=>{t=s.text;return JSON.parse(t.substring(t.indexOf("(")+1,t.indexOf(")")).replaceAll(/({|, )([a-z])/g,'$1"$2').replaceAll(/([a-z])(:[ [])/g,'$1"$2').replaceAll("'",'"')).data[1].map(p=>p[4]+" ("+p[2][3]+" "+p[2][2]+") - "+p[0][0][0])}).forEach(p=>console.log(p))

You should see a list of devices connected to your Google account, their models, and your GSF ID for each, which you can paste into the registration page.

Readable code:

// For each data key (e.g. "ds:0"), find its <script> tag
window.AF_initDataKeys.map(
    key => document.querySelector(
        "script." + CSS.escape(key)
    )
).flatMap(
    scriptTag => {
        scriptText = scriptTag.text;
        return JSON.parse(
            scriptText
            // Take just the {...} passed into AF_initDataCallback()
            .substring(
                scriptText.indexOf("(") + 1,
                scriptText.indexOf(")")
            )
            // Insert quotes before keywords
            .replaceAll(/({|, )([a-z])/g, '$1"$2')
            .replaceAll(/([a-z])(:[ [])/g, '$1"$2')
            // JSON requires double quotes
            .replaceAll("'",'"')
        ).data[1]
        // Make each phone's info info readable
        .map(
            ph => (
                ph[4] // Name
                + " ("
                + ph[2][3] // Manufacturer
                + " "
                + ph[2][2] // Model
                + ") - "
                + ph[0][0][0] // GSF ID
))})
// And print the info
.forEach(
    phone => console.log(phone)
)

Sorry for my javascript sins, it’s not a language I like much or know well. Also sorry for the regex crimes in there - I couldn’t find the parsed data, and Google disables eval() with CSP.

If Google changes something and that code stops working, you may be able to load the Find Hub, press Ctrl+U (Mac Firefox: Cmd+U, Mac Chrome: Cmd+Opt+U), and search for your device name. There should be a 19-digit number near it.

Good luck, and don’t forget to write your congresscritters and demand better antitrust enforcement.

Long Distance 2

mal@sec.gd (mal) — Sun, 28 Jan 2024 23:00:00 +0000

This weekend I participated in the Real World CTF with WreckTheLine. Unlike many other CTFs, these challenges were all based on real applications and systems. It’s interesting being able to use (and gain) domain knowledge, and while contrived challenges are fun, exploiting a system that exists in the real world – on the real internet – is another level of engagement.

Challenge

This misc challenge consisted of a 290 MB WAV file named 486_375MHz-1MSps-1MHz.wav, an 8 MB flash_dump, and a mandate to recover the information contained in the transmission:

Of late, whispers doth persist behind mine back. Yesterday, under the studio tower, a peculiar contraption was found by me. I am most intrigued to discover the content of their discourse.

RF

The WAV file metadata showed 51 seconds, 2 channels, 24 bit resolution, and 1 MHz sample rate. Audibly, it was a mostly silent with several bursts of data, sounding like a pop followed by buzzing.

Audacity was in the mood for 3 hours of plugin updates, so I used Sonic Visualiser, which showed the bursts of data in the waveform. Zooming in, things became more interesting - FM? We can use the spectrogram tool to see the distribution of energy (color) across frequencies (Y axis) over time (X axis), with an interesting result… And further into the data section, discontinuities in the frequency sweeps - Probably the symbols that we needed recover data from.

A teammate, qwertboy, had linked a writeup of last year’s Long Distance challenge by the organizers team, where they had a similar file containing a RF capture, and found the flag by decoding the LoRaWAN traffic.

What I was seeing matched signals they found. Both had similar patterns in the waveform and demodulated FM, and after setting up GNU Radio, in the constellation display.

Flash Image

My first port of call with an unknown firmware image is usually binwalk. In this case the signatures and strings it found led me to believe that this was an image for an ESP32, used mesh networking, and (incorrectly) that it might be for an IoT lightbulb or lighting controller.

$ binwalk flash_dump

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
88595         0x15A13         Neighborly text, "neighbors a simple (0 id) broadcast"
109607        0x1AC27         HTML document header
109988        0x1ADA4         HTML document footer
113954        0x1BD22         Neighborly text, "Neighbor Info module config: Ambient Lighting"
114583        0x1BF97         Neighborly text, "Neighbor Info module config: Ambient Lighting"
118036        0x1CD14         Neighborly text, "NeighborsKET from Node 0x%x to Node 0x%x (last sent by 0x%x)"

[...]
155668        0x26014         Unix path: /home/runner/.platformio/packages/framework-arduinoespressif32/libraries/SPI/src/SPI.cpp
173532        0x2A5DC         AES S-Box
[...]

Extracting the identified files with binwalk -e found assorted HTML and CSS, along with a JSON blob from 0x3A7000:

{
  "name": "Meshtastic",
  "short_name": "Meshtastic",
  "start_url": ".",
  "description": "Meshtastic web app",
  "icons": [
    {
      "src": "/icon.svg",
      "sizes": "any",
      "type": "image/svg+xml"
    }
  ],
  "theme_color": "#67ea94",
  "background_color": "#67ea94",
  "display": "standalone"
}

So I knew early that we’re working with Meshtastic, but didn’t yet understand LoRa vs LoRaWAN. Reading through the site found radio settings to help with decoding, the Meshtastic packet header format to help with parsing, and an overview of the encryption. I later found a diagram of a LoRa Meshtastic packet which was useful, but note the backwards flags field.

LoRa

I spent quite a while trying to get rpp0/gr-lora set up (it officially requires the long-dead python2) and working, and a while more seeing if tapparelj/gr-lora_sdr or its fork martynvdijke/gr-lora_sdr (as used by the AUR package) were any more cooperative. In the end, I replaced the python2-foo dependencies with python3-foo, and it didn’t complain. Still, the correct configuration for the decoder eluded me.

Saturday morning started with another teammate, tcode2k16, finding a potential signal decoding result before I’d finished breakfast. We individually chased our tails for a while on this, and it turned out to have two issues - The decoded data was incorrect, and we were confusing LoRa (physical layer) with LoRaWAN (a communication protocol built on LoRa) and trying to parse the payload as the latter.

We Need to Go Deeper

Once tcode was making progress on decoding and parsing, I went back to the firmware image. The source for this build, less any CTF modifications, is at meshtastic/firmware@v2.2.14.57542ce, and tcode found a default AES key there, but we should check for a custom one in flash.

To start, I dropped the image into a hex editor, which wasn’t particularly useful until I looked into how ESP-IDF partitioning works. The default partition table isn’t at the beginning of flash, but at 0x8000.

Rather than spend time parsing the partition table correctly, I guessed the layout based on the hex dump:

00008000  aa 50 01 02 00 90 00 00  00 50 00 00 6e 76 73 00  |.P.......P..nvs.|
00008010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00008020  aa 50 01 00 00 e0 00 00  00 20 00 00 6f 74 61 64  |.P....... ..otad|
00008030  61 74 61 00 00 00 00 00  00 00 00 00 00 00 00 00  |ata.............|
00008040  aa 50 00 10 00 00 01 00  00 00 25 00 61 70 70 00  |.P........%.app.|
00008050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00008060  aa 50 00 11 00 00 26 00  00 00 0a 00 66 6c 61 73  |.P....&.....flas|
00008070  68 41 70 70 00 00 00 00  00 00 00 00 00 00 00 00  |hApp............|
00008080  aa 50 01 82 00 00 30 00  00 00 10 00 73 70 69 66  |.P....0.....spif|
00008090  66 73 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |fs..............|

Much later I realized the partition table, human-readable with extra info, is also available right in the firmware repository as partition-table.csv. Here’s that version, to save at least one of us some squinting at hex:

# Name,   Type, SubType, Offset,  Size, Flags
nvs,      data, nvs,     0x009000, 0x005000,
otadata,  data, ota,     0x00e000, 0x002000,
app,      app,  ota_0,   0x010000, 0x250000,
flashApp, app,  ota_1,   0x260000, 0x0A0000,
spiffs,   data, spiffs,  0x300000, 0x100000,

“NVS” is used by the ESP-IDF Non-Volatile Storage Library, which seemed like a good place to store settings. Carve out 0x5000 bytes starting at 0x9000 in the image with dd if=flash_dump bs=$((0x1000)) skip=9 count=5 of=nvs.bin, and parse it with nvs_tool.py from the ESP-IDF repository: python nvs_tool.py -i nvs.bin. Unfortunately none of the data it held looked like a 128-bit or 256-bit AES key, or for that matter, any of the other configuration parameters I was expecting.

Where else would the firmware store its configuration? Looking back at the partition table, “nvs” was a bust, “otadata” seems update-related, “app” is probably the running code, “flashApp” may be for in-progress updates, or “spiffs”. The “SPI Flash FileSystem” sounded promising, so I extricated it with dd if=flash_dump bs=$((0x100000)) skip=3 count=1 of=spiffs.bin, but igrr/mkspiffs didn’t like it. file wasn’t familiar. hexdump showed this at the beginning of the file:

00000000  03 00 00 00 f0 0f ff f7  6c 69 74 74 6c 65 66 73  |........littlefs|

Ah. littlefs on a partition named spiffs. Probably some backwards-compatibility thing…

Regardless, the littlefs readme had a lot of useful tools. tniessen/littlefs-disk-img-viewer is a webapp with a live demo, which after some block size guessing (4096) was able to read the filesystem. static/ held the Meshtastic webui resources, and prefs/ had channels.proto, config.proto, and db.proto, which I downloaded.

Protobuf

Protobuf (protocol buffers) is a relatively common data interchange system, which Meshtastic uses for both preferences and over-the-air communication. At first I tried to use protoc with the Meshtastic protobuf definitions to produce Python code to read the files, and then protobufpal, but they weren’t parsing the prefs files, so in the interest of time I ended up using mildsunrise/protobuf-inspector.

$ protobuf_inspector <channels.proto
root:
    1 <chunk> = message:
        2 <chunk> = message:
            2 <chunk> = bytes (1)
                0000   01                                                                       .
        3 <varint> = 1
    1 <chunk> = message:
        1 <varint> = 1
        2 <chunk> = message:
            2 <chunk> = bytes (32)
                0000   CE F8 DB 8E 8E 60 17 FD 6D CC A2 1D B8 A1 47 6D 45 14 80 AC D7 F4 F9 F7  .....`..m.....GmE.......
                0018   69 A7 63 F5 28 C0 11 F7                                                  i.c.(...
            3 <chunk> = "Buddies"
            4 <32bit> = 0x00000001 / 1 / 1.40130e-45
        3 <varint> = 2
    1 <chunk> = message(1 <varint> = 2, 2 <chunk> = empty chunk)
    1 <chunk> = message(1 <varint> = 3, 2 <chunk> = empty chunk)
    1 <chunk> = message(1 <varint> = 4, 2 <chunk> = empty chunk)
    1 <chunk> = message(1 <varint> = 5, 2 <chunk> = empty chunk)
    1 <chunk> = message(1 <varint> = 6, 2 <chunk> = empty chunk)
    1 <chunk> = message(1 <varint> = 7, 2 <chunk> = empty chunk)
    2 <varint> = 22

The leading number associates a value with its attribute in the protobuf definition. The root seems to be an array of Channel objects, so within each of those we should be able to look for the attribute numbers in channel.proto. Channel->2 is a ChannelSettings settings, and ChannelSettings->2 is bytes psk. We’ve found our channel key!

Since then I’ve realized that prefs/channels.proto isn’t a Channel from channel.proto, it’s a ChannelFile from deviceonly.proto, so here’s the interesting parts in a more readable format:

{
  "channels": [
    {
      "index": 0,
      "settings": {...},
      "role": "PRIMARY"
    },
    {
      "index": 1,
      "settings": {
        "channel_num": 0,
        "psk": [
            206,248,219,142,142,96,23,253,109,204,162,29,184,161,71,109,
            69,20,128,172,215,244,249,247,105,167,99,245,40,192,17,247
        ],
        "name": "Buddies",
        "id": 1,
        "uplink_enabled": false,
        "downlink_enabled": false
      },
      "role": "SECONDARY"
    },
    [followed by 6 empty role: DISABLED channels]
  ],
  "version": 22
}

And the LoRa part of prefs/config.proto:

{
  "lora": {
    "ignore_incoming": [],
    "use_preset": true,
    "modem_preset": "LONG_FAST",
    "bandwidth": 0,
    "spread_factor": 0,
    "coding_rate": 0,
    "frequency_offset": 0,
    "region": "CN",
    "hop_limit": 3,
    "tx_enabled": true,
    "tx_power": 19,
    "channel_num": 66,
    "override_duty_cycle": false,
    "sx126x_rx_boosted_gain": true,
    "override_frequency": 0
  }
}

We no longer have to guess our LoRa settings, we can just copy the LONG_FAST parameters from the radio settings page!

Back to Decoding

With known radio settings we could revisit the GNU Radio flow graph with gr-lora. Here’s what I ended up with: download grc

And its output: full log

Bits (nominal) per symbol: 	5.5
Bins per symbol: 	2048
Samples per symbol: 	8192
Decimation: 		4
 2d 31 e0 bc 4b 6c fa c4 c0 6d fa 66 26 d2 02 0b 08 a7 92 b3 78 fb 63 77 d7 e0 54 d7 4f 67 1e c0 2d f1 8c 7d 04 66 c9 31 bb 22 40 0f c9 ec 25 c8 71 33 (Klmf&xcwTOg-}f1"@%q3)
[...]
 22 31 70 ff ff ff ff c4 c0 6d fa 5f 8a 54 22 02 04 a7 92 53 1f 89 a3 6f ea 30 18 c9 ce b7 e7 1f a3 cd 72 71 ed a7 3a (m_T"So0rq:)
 09 11 40/usr/include/c++/13.2.1/bits/stl_vector.h:1125: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = unsigned char; _Alloc = std::allocator<unsigned char>; reference = unsigned char&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.

The crash may have been because of my python2/python3 change. I hoped it wasn’t preventing decoding of the message with the flag, and it turned out fine.

This still looked a bit nonsensical consider the Meshtastic header format. When aligning the first part of each message, I would have expected to see repeated source and destination IDs, channel hash bytes, and padding, and flag bytes with the high nibble empty.

DEST_NODEID SRC_NODEID_ PKT_UNIQ_ID FL CH PAD__ DATA...
2d 31 e0 bc 4b 6c fa c4 c0 6d fa 66 26 d2 02 0b 08 a7 92 b3 78 fb ...
1b 31 e0 c4 c0 6d fa bc 4b 6c fa 29 5d 91 38 03 08 a7 92 12 19 7e ...
49 31 20 c4 c0 6d fa bc 4b 6c fa a6 41 be 1e 0b 08 a7 92 b9 4d 99 ...
1b 31 e0 bc 4b 6c fa c4 c0 6d fa 0f 21 39 44 03 08 a7 92 b8 56 c7 ...
5f 30 00 ff ff ff ff c4 c0 6d fa a3 f3 0f 12 03 08 a7 92 aa c1 8d ...
5f 30 00 ff ff ff ff c4 c0 6d fa a3 f3 0f 12 02 08 a7 92 aa c1 8d ...
...

There are some columns that do have the properties I would expect, though… Let’s shift the column headers over a byte at a time and see if they line up:

?? ?? ?? DEST_NODEID SRC_NODEID_ PKT_UNIQ_ID FL CH PAD__ DATA...
2d 31 e0 bc 4b 6c fa c4 c0 6d fa 66 26 d2 02 0b 08 a7 92 b3 78 fb ...
1b 31 e0 c4 c0 6d fa bc 4b 6c fa 29 5d 91 38 03 08 a7 92 12 19 7e ...
49 31 20 c4 c0 6d fa bc 4b 6c fa a6 41 be 1e 0b 08 a7 92 b9 4d 99 ...
1b 31 e0 bc 4b 6c fa c4 c0 6d fa 0f 21 39 44 03 08 a7 92 b8 56 c7 ...
5f 30 00 ff ff ff ff c4 c0 6d fa a3 f3 0f 12 03 08 a7 92 aa c1 8d ...
5f 30 00 ff ff ff ff c4 c0 6d fa a3 f3 0f 12 02 08 a7 92 aa c1 8d ...
...

That looks better, the fields all had the properties I expected. The leading 3 bytes ended up being the LoRa header, as seen in the diagram - Payload length, coding rate, CRC flag, header CRC, padding.

On to Parsing

Disassembling the headers in python was relatively straightforward, but decrypting the Meshtastic payload was aggravating. The encrypt and decrypt functions are the same for AES-CTR, and for us are in ESP32CryptoEngine.cpp. I should have looked at the relevant bits for other platforms, since they must all be compatible and others are more straightforward, but I didn’t. The problem boiled down to me chasing endianness issues before double checking that I was putting the parts of the nonce together in the wrong order or trying to decrypt other messages.

While I worked on building a custom Counter for PyCryptodome, tcode used my parsing and the python-mbedtls¹ library to successfully decrypt it. A few minutes later I got mine working, using the PyCryptodome, the default Counter, and the correct nonce ordering and message.

#!/usr/bin/env python3

from Crypto.Cipher import AES
from Crypto.Util import Counter


pkt = bytes.fromhex(
    "683060ffffffffc4c06dfa8899c2020304a7925001502e35d73ab793c3e9ad6acc9da6a4955bc56b8054e9989d76f5355cf2868b90bffae321d51077be4e1774fc074f63a4c0af6ba38f33a829b0784bdadbcc738b16e930e741c48f4d6c0cab012e5605122dce40eaeb7b7626"
)
psk = bytes.fromhex(
    "CEF8DB8E8E6017FD6DCCA21DB8A1476D451480ACD7F4F9F769A763F528C011F7"
)

lora_header = pkt[0:3]
has_crc = (lora_header[1] >> 4 & 1) > 0
lora_payload = pkt[3:]
lora_payload_crc = lora_payload[-2:] if has_crc else None
if has_crc:
    lora_payload = lora_payload[:-2]
lora_payload_len = lora_header[0]
if len(lora_payload) != lora_payload_len:
    print(
        "Warning: Incorrect payload length. expected {}, got {}".format(
            lora_payload_len, len(lora_payload)
        )
    )
mt_header = lora_payload[:16]
mt_dest = mt_header[0:4]
mt_src = mt_header[4:8]
mt_packet_id = mt_header[8:12]
mt_flags = mt_header[12]
mt_flags_hop_limit = mt_flags & 0b111
mt_flags_want_ack = (mt_flags >> 3 & 1) > 0
mt_channel_hash = mt_header[13]
mt_header_padding = mt_header[14:16]
mt_payload = lora_payload[16:]

nonce = mt_packet_id + b"\0" * 4 + mt_src
cipher = AES.new(psk, AES.MODE_CTR, initial_value=0, nonce=nonce)
mt_payload_decrypted = cipher.decrypt(mt_payload)

open("decrypt.out", "wb").write(mt_payload_decrypted)
print(mt_payload_decrypted)

Victory!

b'\x08\x01\x12Talright alright. the key is rwctf{No_h0p_th1s_tim3_c831bcad725935ba25c0a3708e49c0c8}'

Fully parsed:

{
  "portnum": "TEXT_MESSAGE_APP",
  "payload": "alright alright. the key is rwctf{No_h0p_th1s_tim3_c831bcad725935ba25c0a3708e49c0c8}"
}

Conclusion

Thanks to tcode for working with me on this challenge. At one point during decoding they said “I was doing something silly”. In my experience, that’s all of programming, CTFing, and many other technical endeavors. I hope this post was worth the read despite its length, but I think it’s important to not gloss over the challenges and mistakes instead of reinforcing anyone’s imposter syndrome.

WreckTheLine finished in 7th place of 2291 teams. This challenge was worth 320 points out of our 1662 (19%), and was solved by a total of 9 teams.

I would recommend against using Synss/python-mbedtls for real cryptography. It has basically no documentation I can find besides examples, and what is there (docstrings) is scary. For example, AES.new(key, mode, iv, ad) (note that iv=nonce+counter, effectively):

iv: The initialization vector (IV). The IV is required for every mode but ECB and CTR where it is ignored. If not set, the IV is initialized to all 0, which should not be used for encryption.

AES-CTR must never use the same (key, nonce, counter) twice or its security properties are broken. Luckily failing to specify an iv parameter does produce an error. Additionally, the ad (Associated Data / Additional Authenticated Data, I assume) parameter is not even in the docstring. ↩︎

Hacker's Playground: Legonigma

mal@sec.gd (mal) — Tue, 27 Sep 2022 04:00:00 +0000

I recently participated in Samsung’s Hacker’s Playground CTF with Wreck The Line. We finished with 1592 points, in 26th place of 1075 teams. Most of my time was spent on Legonigma, an interesting 500 point challenge based on two renders of a Lego cryptography gadget.

The Challenge

Decipher ciphertext: 59x8wl9pjsava3grn0il79aoq307f20a6huc3xnos289cd8xv1fn2znuoa2bq8959chbktwfow8c3azpvo3c59jz4

First Impressions

Cool!

I had a limited selection of possible parts, assuming it was built with production Lego pieces. The only moving parts were gears and a differential, so I suspected the relationships between input and outputs were just a series of ratios.

Why were there three outputs? Maybe it produced 3 ciphertext characters per plaintext character? No, the ciphertext was 89 characters total, which isn’t divisible by 3… I must need to guess the order?

Pieces in Play

Using the images and information from a blog post about Lego gears I listed the pieces I might face, by type, tooth count, and features:

Regular gears (no bevel)
- 8 (axle)
- 16 (axle and small spaces)
- 24 (axle and four round post holes)
- 40 (axle and a bunch of axle and post holes)
Double Bevel
- 12 (axle)
- 20 (axle, spaces)
- 28 (axle and four post holes)
- 36 (axle plus two posts and two axles)
Differential
- Three identical single-bevel inside, so ratios don’t matter
- Outside: 16 and 24 tooth

Attempt One: Procedural

My first instinct was to follow the gearing through, noting each number of teeth:

36 (input, green)
hard link to 20 (grey)
rotates 12 (blue)
rotates 20 (grey)
splits to A

A1:
rotates 12 (blue)
hard link to 36 (grey)
rotates 12 (blue)
hard link to 36 (yellow, out1)

A2:
hard link to 28 (blue)
...

I intended to turn this into a simple procedure that would just do the math for each step, keeping track of the angle of each gear, but I realized there’s a much easier way to simplify it…

Attempt Two: Mathematical

If I pretend I’ve turned the input one full rotation clockwise, how does each gear – and therefore each output – behave?

input 1 CW
grey 1 CW
blue (irrelevant) CCW
grey 1 CW (split A)

A1 (left):
blue 20/12=5/3 CCW
grey 5/3 CCW
blue 5 CW
yellow 5 CW (out1)

A2:
blue (irrelevant) CCW
grey 1 CW
blue 20/12=5/3 CCW (split B)

...

Following this through, I arrived at the following ratios between input and output:

1:5 for the front left output
1:5/3 for the front right output
1:38/9 for the rear output

Having made up simple ciphers in the past, after finding the 1:5 output I was kind of expecting the others to also be prime numbers. Oh well, the math doesn’t lie… Right?

But after writing some python code to show outputs for every possible first couple characters of input, I couldn’t get the outputs to match the ciphertext. Notably, for lots of valid inputs, the rear and right-side outputs sat between letters. Unless this machine would be provided to users with specific instructions, that seemed odd.

I spent a long time chasing guesses about what those instructions might be - “Keep turning until the outputs are all exactly at a tooth/letter”? “Keep turning until the one output for this step is exactly at a tooth/letter”? After some rubber duck debugging and a gentle nudge from the challenge author, I re-examined my understanding of the machine, but still couldn’t find anything wrong.

The Nuclear Option

If I couldn’t logic it out, I’d try to rebuild the device’s mechanics using a tool.

There were several relatively simple tools for Lego gear ratios, but besides them being a bit difficult to build a complex machine in, it didn’t seem they would be able to handle the differential, or possibly even the splits.

I ended up finding the Technic Brick Power Gearing Ratio Calculator, which seemed to do exactly what I needed! …when provided with a “Lego Technic .ldr file”. Okay, it seems I need to use something like LeoCAD to build that…

A lot of twiddling and building later, I had reproduced the machine:

But when I loaded it into the gearing ratio tool, attaching a motor, and running it, the entire model turned red, indicating a jammed motor.

I assumed the tool just didn’t know how to handle the differential, and removed the gear before the rear output to let both sides of that branch run separately, then combined the adjacent gears’ motion myself. The results matched my original calculations perfectly, and I was lost again.

After many more lines of code and attempts to figure out how the machine would be used, I eventually arrived at a realization: In a row of three gears, turning the first clockwise at 1 RPM and the third clockwise at 2 RPM does not cause the middle one to rotate counterclockwise at 3 RPM. Don’t ask how I had arrived at my original understanding – I do not know, and it is as obviously wrong in retrospect as it is to you. The resulting conclusion was that the branch through the front-right output and the differential was not modifying the ratio of the rear output. The simulation was correct. My understanding of the machine actually was a deadlock.

I stared at the challenge’s renders more, and eventually found the problem: There was in fact no motion going through the front-right output’s axle, and the direction of control through the differential is the opposite of what I thought.

See it? I sure didn’t.

After some logic, some trial-and error, and a lot of staring at close-ups of small details in the original render, I moved a few elements around. Here’s a bottom view of the change, with the front-right output gear at the top center:

Then I loaded the amended model into the simulator:

Your browser does not seem to support this video.

And got some much nicer ratios for the outputs…

So I updated my code to use these much more reasonable ratios, aaaaand… No valid input produced an output matching the first three characters of ciphertext.

Reaching further

Lacking any idea how the outputs were meant to be read, I figured it was time to investigate the challenge name’s call-out to the German Enigma machine to look for hints.

Enigma

Known-plaintext attack
Not ECB (advances rotors by each character)
Random mapping in each code wheel and on plugboard
Never encrypted a letter to itself
Decryption == encryption (if a->r, r->a)
Key is rotor selection, rotor position, reflector position, plugboard config

This machine

No known-plaintext available
ECB (all rotors end up back at A when input is rotated back to A)
Probably not enough ciphertext to do statistics for random mappings
Encrypts A to A,A,A
How to decrypt, besides “turn input til all three outputs match your ciphertext block”?
If there’s a key, how is it configured? 4 pointer positions * 4 rotors * 6 output rotor orders = 96 possibilities?

Maybe I was missing an instruction like “Advance the input by n teeth, where n is the index of the next plaintext character”? I couldn’t figure out how to turn the three outputs into a ciphertext.

Feeling Dumb (Again)

There’s no galaxy brain instructions, I just needed read the outputs in a particular order, trivially discovered. 1:13 first, then 1:5, then 1:7.

I achieved the second solve for Legonigma, for 460 points, 17 minutes after the first team. SCTF{th3w0rld1sadang3rou5placeno7becau5e0fth0sewh0do3v1lbutbecau5eofth053wh0l00konandd0n0th1ng} (“The world is a dangerous place, not because of those who do evil, but because of those who look on and do nothing”)

Conclusion

I wish the ratios hadn’t been whole numbers, so the “no reversing” instruction meant something!

Thanks to “Your expectations are reasonable” Cybrosis for a really neat challenge and a couple nudges, rebuilding the machine was fun. Thanks also to Samsung for organizing this event, and my teammates at WreckTheLine for all of their work and for putting up with my rubber ducking.

Downloads

My Python code, including a lot of commented-out wrong attempts, and overbuilt since I originally expected one full input rotation to not return to the starting state: legonigma.py

The .ldr model of the machine I built in LeoCAD: legonigma.ldr

1Password's Privacy Surprises

mal@sec.gd (mal) — Wed, 04 Aug 2021 04:00:00 +0000

1Password is a popular password manager by AgileBits. It’s much more reliable and user-friendly than LastPass, and has a $60/yr family plan¹, so it’s what my family uses to keep track of and share credentials.

Unfortunately it has a couple of design problems that AgileBits does not feel should be fixed.

To be clear up front: These are not critical vulnerabilities. They do not allow strangers to read your passwords. I still use 1Password, and am not recommending most people stop using them, only understand these limitations.

Family Organizer Vault Takeover

Users of 1Password can create additional vaults. This is how users share stored items (i.e. login information) between accounts: Create vault, share vault with other user, move Netflix password into shared vault.

This feature also enables separation of stored items between personal, school, work, and alternate identities. It’s useful to be able to put some things away by switching vaults or removing some vaults from All Vaults when traveling (see also: Travel Mode), hosting a screenshare, or in some physical environments (work, school, church).

The Problem

What isn’t mentioned anywhere in the vault creation process is that if you’re using a family plan the family organizers can add themselves to these additional vaults. That information is only shown on the easily missable Vault Details page, and isn’t even clear in their documentation.

I first discovered this when I noticed I could add myself to a vault shared between my parents and grant myself full permissions. I wrote to their support in 2019 asking if this was intended and how to create a vault organizers couldn’t add themselves to. Their first response actually said that family organizers “cannot manage any of your vaults unless they have explicit permission to that vault”, which would be great if not demonstrably untrue. When asked for clarification, I was informed that only the default vault named “Private” is inaccessable, and all others can be accessed by family organizers.

Family organizers can see all secondary vaults created by family members.

They can see the details, delete the vault, or manage its users.

Just a checkbox to gain access.

I wonder what they’re hiding from me? Luckily, I have no morals, so I can find out without having to interact with my child.

When I add myself to a vault this way, there are no notifications, confirmations, or logs². I can add myself, create a backup of the entire vault, and remove myself, and the authorized users would never know.

At best, this makes vaults useless for many situations. I’m contractually prohibited from sharing some credentials with anyone else, so if I add another family organizer as best practice suggests, I can no longer separate work credentials using a vault.

At worst, this could allow a parent to violate a child’s privacy in unexpected ways, or an employer to violate an employee’s³ - not just revealing the sites used but directly and unauditably granting access to them.

If this was clear to users, I would be disappointed, but I wouldn’t be writing this post. The problem is that it’s not - it’s unexpected in the most unpleasant way from a password manager.

Potential Mitigations

Minimum

Transparency. Make clear in the vault creation flow that family organizers can gain access to it. Send a notification and/or email to authorized vault users on membership changes.

Preferred

Cryptographic and server control. Do not encrypt vault keys for anyone not explicitly authorized to have access except in the same manner as account recovery, and do not send the vault data to anyone not explicitly authorized.

Workarounds

As support suggested to me, use tags instead of vaults, and give up the vault-based features.
Abandon redundancy and be the only family organizer, and tell your family members that they aren’t able to create vaults you don’t have access to.
Use only individual accounts, giving up the family plan discount and group-based features.

Leaking Metadata to Network Admins

Unlike the first, this problem applies to all accounts - Individual, family, and business, whether subscription or app-licensed. When the 1Password app or browser addon shows vault entries, it shows an icon for each website. Instead of being saved in your vault, they’re requested from the server when they’re shown. The Windows desktop app appears to cache them, but the browser addon appears to request them again each time they’re shown.

Normally the privacy impact of this is what they describe on their rich icon privacy page: Your network sees that you use 1password, and the CDN sees your IP address and the domain you’re requesting an icon for. This isn’t ideal but is acceptable to most users. Others can disable it, assuming they notice and understand the setting, and that they’re not using the browser extension, where the setting doesn’t exist.

The Problem

Many schools and companies use SSL/TLS inspection (TLSi) either to restrict what content is available from the network or to ensure sensitive information is not being sent out of the network. TLSi works by requiring every device to add a new trusted certificate authority, and then signing a new TLS certificate for every site a device tries to contact. The end result is that the user sees the usual 🔒 https://... in their browser and everything works normally, but when their traffic reaches the system performing inspection, it’s decrypted, scanned, potentially logged, and then re-encrypted and passed along.

This means that every time the user clicks the 1Password button, opens their vault, or has the autofill popover show up, their school or workplace will get logs like these:

SSL added and removed here! :)

Depending on the domain and the aggressiveness of web filters, this may even trigger automated alerts to administrators, including the wildly inappropriate “adult content” classification for LGBTQ+ resources. These alerts are often passed along to parents or supervisors for disciplinary action.

When I contacted support about this, I was referred to their rich icon privacy documentation page.

Users expect password managers to do everything possible to keep their contents, including the metadata, private. In situations where an unavoidable environment like work or school may disagree with parts of a 1Password user’s personal life, this expectation is put to the test, and its failure may have significant consequences.

Potential Mitigations

Ideally, store images encrypted for the user, encrypt requests. This would increase server disk space needs and load. Alternatively:
Pin the keys of the CDNs so inspection devices don’t see the requested URLs. This slightly degrades the user experinece, but I feel this is a more than acceptable tradeoff in those cases. Unfortunately this probably isn’t possible in the browser extension.
Implement a setting to disable rich icons in the browser addon
Obfuscate, e.g. encrypt images with hash(domain), request with hash(hash(domain)). Defeats trivial observation, but doesn’t prevent confirmation of known domains.
Cache icons for as long as possible to reduce the amount/chance of information leaking.

Workarounds

Don’t use 1Password in TLS-inspected environments.
Disable vaults containing sensitive domains when in a TLS-inspected environment, if the above issue with vaults doesn’t preclude their use.
I haven’t found a way to block the requests with uBlock Origin or even uMatrix, so… Accept the risk, or disable the browser addon when in TLS-inspected environments.
Disable rich icons in settings, or don’t use the apps either in TLS-inspected environments.
Ideally, use a VPN like Wireguard to escape TLS-inspected environments and never install new trusted certificate authorities regardless of this issue.

1Password CLI Leaks

Added 2021-09-29

As reported by Graham Christensen, the 1Password CLI tool (op) exposes sensitive information including passwords to all other users and processes on your system through command arguments.

AgileBits are aware of this and consider it not a problem.

“Luckily”, unlike other password managers’ command line tools, op is quite difficult to use as a human - its interfaces almost seem to be intended as an API instead of for direct use.

Read more about this problem in Graham’s twitter thread

Mal Whining

While I’m writing about 1Password, I may as well mention the other things that I’d like to see changed.

Inactive Account Management

As described in the whitepaper, there is a mechanism for assisting family members or team members with vault recovery. A simplified explanation is that the server holds a copy of each family member’s vault key, encrypted so only family organizers can access it. If I initiate recovery for my mother’s vault, she receives an email allowing her to create new keys. Once she’s done so, the server gives me the encrypted vault key (but not the vault data) so I can re-encrypt it with her new public key.

This is about as good as I can ask for a user-friendly recovery system, but I would like to see the ability to configure my account to grant access to specific vaults to a family member if I don’t sign in for some number of months and don’t respond to emails or text messages.

The cryptographic features are already there, this mode would just skip the email confirmation, and the server would grant vault data access as well.

Backups

As mentioned, the Linux app is not feature-complete, and there’s no way to grant access to vaults automatically if I’m run over by a bus. It would be great if the ability to make backups was prioritized for either Linux or the web interface.

Container Incompatibility

Firefox has a great feature called Container Tabs that allows easy separation of multiple accounts, identities, or contexts. I use it extensively to keep work accounts in one container, personal in another, and stay signed out in the default container.

When selecting “Open & Fill” in the 1Password extension, it creates a new tab in the default container, and uses that to navigate to the site. This means the only way to sign in to a site in a chosen container is to copy the link and paste it into a new container tab manually.

I brought this up on their forum in 2018, and for a few versions the extension would reuse the existing new container tab if present, but then it stopped working again, and they still haven’t fixed it.

If they wanted to, they could build neat integrations, like having the extension always open a login (or even just anything in a particular vault) in a configured container. For now, all I ask is to not override my choice.

Getting to the web interface

Nearly all of the management of vault items and account settings is done through either the web interface or one of the applications. The Linux app is currently in beta and not feature-complete, and typing on a phone is tedious, so I’m left with the web app. (2022 update: The linux app is improving, and I can access that by clicking the icon in my taskbar, but this annoyance remains for those who don’t use the desktop app.)

To access the web app, I can either go to the site and enter my password again, or I can have the extension open it alreay authenticated.

For some reason, the only way I’ve found to do this is to click the extension’s icon, click the settings gear, click Settings, scroll to the bottom, click one of the vault names, and then navigate where I need to go in the web interface.

Could we get a link next to Settings that’s just “Manage from web”?

1Password is also available without the web/sync features as a one-time purchase. I expect everything described here to apply to that use as well, but it’s not what AgileBits are pushing, and I don’t want to buy it to test. ↩︎
Business plans may expose audit logs. I don’t have one to test, but I would be surprised if those logs were made available to normal users. ↩︎
This is less clear, as many employers have policies stating employees have no expectation of privacy. I would argue that employees should be reminded of this at every point where it might be important. ↩︎

ImaginaryCTF 2021

mal@sec.gd (mal) — Tue, 27 Jul 2021 04:00:00 +0000

This weekend I participated in ImaginaryCTF 2021 with WreckTheLine. We finished third out of 1018 entrants, the final team to complete all 55 challenges and hit 11330 points, missing second place by 3.5 minutes.

System Hardening 5

“CyberPatriot but run by roo fanatics… What could go wrong…”

At 450 points, System Hardening 5 was in the highest value category of challenges. It was in the pattern of CyberPatriot, where teams download and run a VM, find and fix all of the vulnerabilities. A scoring engine checks the scored items every minute or so and reports to the scoreboard.

As with CyberPatriot, we start with the readme. The major constrants today are:

No updates at all. Makes sense, that’s time-consuming and uninteresting.
Critical services: Remote desktop, print spooler.
Don’t disable SMB or the scoring engine may break

Forensics

Let’s start¹ with the Forensics questions, as the readme says, so we don’t accidentally destroy artifacts we’ll need to answer them.

An [sic] user on this system was compromised, allowing rooReaper to break in. What is the username of this user?

Well, let’s look around. Event log? Exploit artifacts? Let’s check this other file on the desktop first, text-messages-from-mom.txt.txt [sic].

MOMtotallynotrooreaper: hi roo! this is definitely mom here
rooYay: oh hi mom didnt see you there all too well
MOMtotallynotrooreaper: ?
rooYay: nvm, what did you text me for
rooYay: and is this a new number? i dont see the message history
MOMtotallynotrooreaper: uhh yea this is a new number
rooYay: oh ok
MOMtotallynotrooreaper: can you disable your firewall? and enable smb pls and disable your antivirus
rooYay: ok whatever you say mom…
rooYay: ill look up some tutorials
MOMtotallynotrooreaper: NO DONT LOOK AT TUTORIALS
rooYay: ok i wont what do i do
MOMtotallynotrooreaper: ill show you
MOMtotallynotrooreaper: btw what is rooPOG’s password
MOMtotallynotrooreaper: i heard he loves sharing
rooYay: its just password1337 nothing fancy
MOMtotallynotrooreaper: thanks!
…

Looks like rooYay fell for the classic “hi this is your mother” phish, and gave out rooPOG’s password.

Forensics Question 1 correct - 7 points

That also gives us the answer to the next forensics question:

What is the password of the compromised user from the previous question?

password1337 nothing fancy

Forensics Question 2 correct - 7 points

The other forensics questions require some research.

What is the CVE ID of the vulnerability that allowed rooReaper to escalate privileges?

I poked around in rooPOG’s home directory for a bit, finding xconsole.exe and vlib.dll in Downloads\foobar. The latter was detected as Win32/Mamson.A!ac, which doesn’t obviously use any exploits. I enabled Windows Defender and started a scan, and before I had found anything in the event viewer, it had found C:\temp\PrintNightmareLPE.exe.

Print Nightmare, CVE-2021-34527, is a recent vulnerability that allows a remote attacker to install a malicious printer driver configuration DLL to gain arbitrary code execution as SYSTEM. A variant, CVE-2021-1675, is useful for local exploitation, and was accepted as the answer.

Both of these drop the payload, in this case vlib.dll, in C:\Windows\System32\spool\drivers\x64\3\, where Defender found it alongside reverse_64bit.dll which it detected as Win64/Meterpreter.B. I removed the whole folder, along with C:\temp\ and the contents of rooPOG’s Downloads folder.

Forensics Question 3 correct - 7 points
Removed privilege escalation payload - 5 points

The final forensics question seemed like a steganography problem, but referred to another challenge in the CTF:

The background image on the Desktop contains a secret message. What is it?
HINT: It’s related to another challenge in this CTF, a reversing challenge.

The wallpaper was background.png in rooYay’s Pictures folder. It consisted of a grid of tiles, in a repeating pattern Axxxx, where there were 3 options for x. No obvious pattern was shown by stegsolve, and it wasn’t clear how to decode information in the tile pattern. I put it aside until a teammate, JaGoTu, solved roolang, which seemed potentially-related. Sure enough:

JaGoTu: roolang was just a vm that was calculating fibonacii very slowly
JaGoTu: can you send the raw png somewhere?
JaGoTu: cause the roolang basically runs png files

They ran their roolang solution on the PNG, and sent back the output: Hello, and welcome to the roos’ server!

Forensics Question 4 correct - 7 points

PUPs (Not the Fun Kind)

With the forensics questions out of the way, let’s continue through the readme. We have a list of needed services and software, so let’s remove anything that’s not on it, starting with the faux-Clippy in the corner of the screen.

First, the Startup folder for All Users in C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\. Two shortcuts:\

chksec - Shortcut.lnk to C:\Windows\System32\chksec.exe
essential - Shortcut.lnk to C:\Windows\System32\essential.bat

Delete the shortcuts, kill the processes, delete the Clippy executable. essential.bat printed some ascii art text, copied itself to the current user’s start menu Startup folder, opened a video, and then paused. Delete the batch file from System32 and from rooYay’s %AppData%\Microsoft\Windows\Start Menu\Programs\Startup\.

Removed PUP Clippy - 3 points
Removed rickroll malware - 4 points

Installed Programs

There’s a couple shortcuts on the desktop to software that wasn’t mentioned as required in the readme, so let’s remove those. I replaced Chrome with Firefox portable, since the roos prefer IE and I very much do not. Nothing else in add/remove programs looked relevant.

Removed unauthorized program Minecraft Launcher - 3 points
Removed unauthorized program SuperAntiSpyware - 3 points

I also looked through the running processes, but nothing else there raised suspicion.

Users

Next, let’s deal with users, which is easiest from compmgmt.msc/lusrmgr.msc.

Create roocursion as requested in the readme
Rename the local administrator account as requested (can be done here or in group policy)
Make sure nobody unauthorized is in Administrators or other privileged groups
Make sure no non-builtin users exist who aren’t mentioned, poking through their home folders before deleting
Disable the Guest account, and rename for good measure
Change the password for all users

I’ll mention here that CyberPatriot often uses significantly outdated best practices and ignores how things would be done in the real world, and we also don’t know what this challenge will score on, so a lot of the things I check and changes I make to this machine are excessive, paranoid, annoying, or otherwise just weird. If we lose points for something we can easily undo the change.

Removed unauthorized user rooReaper - 3 points
Removed unauthorized user rooDevil - 3 points
Removed unauthorized user rooRage - 3 points
User rooFrozen is not an administrator - 3 points
User roocursion has been created - 3 points
Administrator account renamed - 3 points
Guest account is disabled - 4 points

Services and Firewall

Interspersed with everything else, I poke around services.msc and the control panel to make sure everything is sane. Enable the firewall MOMtotallynotrooreaper told us to disable, then make sure there’s no nonstandard or scary rules enabled. Enable cloud protection and sample sumbission for Defender, make sure the scan finished. Right click My Computer and click Properties, check $PATH and other environment variables for anything weird, make sure Data Execution Prevention is enabled for all applications, and disable NetBIOS.

Windows Firewall is enabled - 5 points

Group Policy

Before I forget, let’s make sure we’ve mitigated Print Nightmare. The MSRC post about it recommends updating (oops, can’t), disabling the print spooler (oops, can’t), or disabling inbound remote printing with Group Policy.

I fire up gpedit.msc, open Computer Configuration -> Windows Settings -> … Where’s Security Settings?

This is where I spent about half my time on this challenge. When launching gpedit.msc, Security Settings was missing. secpol.msc would show the tree starting at Windows Settings instead of Security Settings, and also omit the latter. Many answers on the internet offered a simple regsvr32 wsecedit.dll, which doesn’t work as the DLL doesn’t have the correct entrypoints for that. This is where I ran dism /online /cleanup-image /restorehealth and sfc /scannow, which didn’t find any problems.

I never did figure out what was done to break that, as I eventually gave up and tried importing an exported policy, and later started setting the policy registry entries by hand. After a while, I opened the mmc snapin again, and Security Settings was there!

It seems that it’s only broken for the rooYay user, and after setting UAC to require a password, I was unintentionally elevating as rooAstro, for whom it worked correctly. Something in my profile was breaking it. Some windows LD_LIBRARY_PATH type thing? Something in HKEY_CURRENT_USER? It didn’t directly affect security, so I put it aside again.

From there, I could much more easily continue with group policy, basically just going through every option in Security Settings -> Account Policies and Local Policies and some folders in Administrative Templates -> Windows Settings, setting everything to the most paranoid sane option.

Remember 24 passwords
60 day maximum password age
10 day minimum password age
14 character minimum length
Must meet complexity requirements
No reversible encryption
15 minute account lockout duration
10 attempt lockout threshold
15 minute counter reset timer
Enable all auditing
Go through User Rights Assignment and restrict everything as much as possible
Hey, why is Everyone allowed to take ownership of files??
You know what, let’s just disable the Administrator account
I don’t like Microsoft account signin
More audit everything
Prevent users from installing printer drivers (well… try to)
Restrict CD-ROM access to locally logged-on users
Require CTRL+ALT+DEL, force inactivity limit, require strong encryption
You get the idea.

Everyone is not allowed to take ownership of files and other objects - 5 points

Critical Services

And let’s not forget to secure our critical services. The MSRC Print Nightmare article points me to Administrative Templates -> Printers to disable “Allow Print Spooler to accept client connections”. There have been a few RDP vulnerabilities, but none with straightforward workarounds besides patching, so let’s just be sure to flip on all of the RDP server security policies. Lastly, we weren’t disallowed from disabling old versions of SMB, so use the powershell command in the docs, to check for SMBv1 and see it’s already disabled.

Inbound remote printing is disabled (PrintNightmare mitigation) - 9 points
Remote Desktop uses network level authentication - 4 points

Other Stuff

In an advanced challenge, in addition to sfc and dism to look for “creatively modified” system files, hijackthis can be helpful. In case of a well-disguised network backdoor, it’s also good to check open sockets.

Conclusion

And with that, I had 91 points, 20/21 items, and the flag appeared in the score report. There was one scored item I never found, worth 9 points. I’ll be waiting for a writeup from tirefire, the only person with 100 points, to see what I missed!

Unique ID: 8edd464b
Flag: ictf{th4nks_s0_much_f0r_s3cur1ng_0ur_s3rver!_h3r3s_4_fl4g!!!}

Update

First, Eth007, one of the challenge authors, let me know that the last scored item I couldn’t find was LSA protection.

Second, thank you to the iCTF team for selecting this as a prize-winning writeup!

New Technology

“If it’s not Windows New Technology, what else could NT stand for?”

This was a 300pt cryptography challenge in the form of a python script. It generates a random key consisting of 5 tuples, each a 512-bit prime p and an integer exponent $1 \le e < 4$.

def gen():
    private = []
    for _ in range(5):
        p = getPrime(512)
        e = getRandomRange(1, 4)
        private.append((p, e))
    return private, normalize(private)

The public key is derived by the normalize() function, which multiplies together p**e for each private key component.

def normalize(fac):
    n = 1
    for p, e in fac:
        n *= p**e
    return n

Since these are 512-bit primes, the resulting public key isn’t easy to factor.

The private key is put through the deriv() function, which has a nested loop based on divs().

def deriv(priv):
    res = 0
    for d1 in divs(priv):
        for d2 in divs(d1):
            res += normalize(d2) * phi(d2) * phi(div(d1, d2))
    return res

divs() takes the same List[Set[prime: int, exponent: int], ...] private key format and yields the cartesian product of them based on the range 0..e of their exponents:

def divs(fac, pre=None):
    if pre is None:
        pre = []
    if not fac:
        yield pre
    else:
        p, e = fac[0]
        for i in range(0, e + 1):
            yield from divs(fac[1:], pre + [(p, i)]

>>> priv = [(167, 1), (149, 2)]
>>> pprint(list(divs(priv)))
[[(167, 0), (149, 0)],
 [(167, 0), (149, 1)],
 [(167, 0), (149, 2)],
 [(167, 1), (149, 0)],
 [(167, 1), (149, 1)],
 [(167, 1), (149, 2)]]

For each entry in this list, d1, deriv() again calls divs(), and loops on that d2, adding normalize(d2) * phi(d2) * phi(div(d1, d2)) to a running total.

def phi(fac):
    res = 1
    for p, e in fac:
        if not e: continue
        res *= (p**(e - 1)) * (p - 1)
    return res

def div(a, b):  # a=d1, b=d2
    b = dict(b)
    res = []
    for p, e in a:
        assert e >= b[p]
        res.append((p, e - b[p]))
    return res

At some point here things started to smell funny - we’re collecting the sum of some math done on every divisor of every divisor… Just for fun, let’s see how this behaves when run all the way through with more manageable numbers, maybe 12 bits.

def gen_custom(count=5, size=512, max_exp=3):
    private = []
    for _ in range(count):
        p = getPrime(size)
        e = getRandomRange(1, max_exp+1)
        private.append((p, e))
    return private, normalize(private)

>>> priv, pub = gen_custom(5, 12, 3)
>>> priv
[(3251, 1), (3863, 1), (2917, 2), (3761, 3), (3989, 2)]
>>> pub
90459172118968888949999762493557
>>> key = deriv(priv)
>>> key
8182861820449238390507452368725018700352715647046709310466512249
>>> from sage.all import *
>>> factor(pub)
2917^2 * 3251 * 3761^3 * 3863 * 3989^2
>>> factor(key)
2917^4 * 3251^2 * 3761^6 * 3863^2 * 3989^4

If you don’t have sagemath installed, you can also use a handy dandy webassembly ECM factorization tool.

The factors of the public key aren’t surprising, that’s the exact math we used to derive it from the private key, but possible to reverse since we used small numbers. On the other hand, what’s up with the private key? Each factor just has double the exponent? And since $x^2 * y^2 = (xy)^2$, and $(x^3)^2 = x^6$… Our private key is just the square of the public key??

>>> key == pub**2
True

Well then! Let’s assign those commented output values to variables, square the public key, get a new AES instance for decrypting, and…

pub = 0x281ab467e16cdedb97a298249bdd334f0cc7d54177ed0946c04ec26da111...
ciphertext = bytes.fromhex("d2463ccc52075674effbad1b1ea5ae9a9c8106f1...")
key = pub**2
cipher = AES.new(
    hashlib.sha256(str(key).encode("utf-8")).digest(),
    AES.MODE_CBC,
    iv=b"\0" * 16,
)
plaintext = cipher.decrypt(ciphertext)
print(plaintext)

And, drumroll… b'ictf{Would_number_theory_be_new_technology?}\x04\x04\x04\x04'! For good practice, let’s clean that up a bit by removing the padding and turning it back into a unicode string:

from Crypto.Util.Padding import unpad
print(unpad(plaintext, 16).decode("utf-8"))

And there we have it!

Flag: ictf{Would_number_theory_be_new_technology?}

Thanks

Thank you to my team for a friendly place to be the dumbest person in the room, and to the ImaginaryCTF platform folks and challenge developers for the interesting and challenging … challenges.

The header image is from the ImaginaryCTF 2021 site (repo), used with permission from Astro.

I’ve taken some liberties with the order I present objectives here, since a writeup that followed my actual path would be impossible to follow. ↩︎

Minimally-Invasive Smart Outlet Surgery

mal@sec.gd (mal) — Fri, 25 Jun 2021 04:49:17 +0000

I have several EFUN SH331W smart outlets for controlling various lights. They’re based on a whitelabel ESP8266 design by Tuya, so I usually use tuya-convert to flash them with Tasmota so I can control them with MQTT. Unfortunately tuya-convert is a rather tedious and error-prone process, and recently I managed to soft-brick one.

Recovery for some devices is easy, you follow the normal Tasmota install instructions: Pop it open, connect TX, RX, GPIO0 to ground, GND, and 3.3v. When GPIO0 (aka pin IO0) is pulled down the ESP boots to flashing mode, and you can use esptool to flash tasmota directly.

Opening this device is less than straightforward — it’s a sealed plastic shell, and even with the most careful disassembly it would be pretty annoying to glue back together.

On the other hand, it would be a shame to have to toss a device that’s only soft-bricked…

Let’s use another one with bad flash memory¹ to see what’s going on inside.

Investigatory Dissection

Or vivisection, I guess?

After a lot of careful cutting and prying around the edges of the unit, and a small blood sacrifice², the innards were revealed. The ESP is its own module, sticking up from the main board, with all of the contacts we need hiding between the main board and the plastic back of the unit.

The module EFUN used is an ESP8266-S3 by Hysiry. We need access to pins 7 (IO0/GPIO0) to pull down for flashing mode, 11 and 12 (URXD/UART0_RXD, UTXD/UART0_TXD) for communication, and 13 and 14 (VCC/VDD, GND) for power. On many devices GPIO0 is connected to the external button, but the Tasmota template for this device shows it’s used by a status LED instead.

At this point I drilled five small holes in the plastic, expecting to stick jumper wires through to touch the solder joints for the module. After spending far too much time trying to hold all five in place with one hand while typing picocom commands with the other, I gave up and desoldered the board from the mains pins so I could add wires.

Now able to make a reliable physical connection, it was time to find several hundred ways not to communicate with it. To make a long story short, the bus pirate continues its legacy of technically working and being just helpful enough to not warrant replacing.

It seems the ESP, at least at this clock speed, uses a baudrate of 74880. This isn’t one the bus pirate offers, so I had to use the “BRG raw value” option.

BRG refers to the PIC Baud Rate Generator and the register used to configure it. It’s described in section 17.1 of the PIC24FJ64GA datasheet. So for this bus pirate’s microcontroller, clock frequency, and firmware that uses BRGH=1, brg=(4000000/baudrate)-1, so for 74880 baud we use a BRG of 52.

Connecting

For wiring, use the bus pirate’s GND to pin 7 and either pin 14 or the neutral prong, 3V3 to pin 13, MOSI to pin 11, and MISO to pin 12. Do not connect mains power.

The final incantation for the bus pirate:
$ picocom -b 115200 /dev/ttyUSB0
b to change host<->bp baudrate
10 for “BRG raw value”
52 for 74880 baud
Ctrl+a Ctrl+b 74880 to set picocom’s baudrate
m to change the bp<->device mode
2 for UART
10 for “BRG raw value”
52 for 74880 baud
Default data bits and parity, stop bits, and receive polarity (8N1, Idle 1)
2 for “Normal (H=3.3V, L=GND)” output
W to enable the power supply
(1) to start transparent bridge mode

You should then be able to see a bootloader message when removing and replacing power for the device. You can exit picocom with Ctrl+a Ctrl+q.

With picocom closed, you can use esptool to communicate with the ESP.

Test communication:
esptool -p /dev/ttyUSB0 --chip esp8266 -b 74880 read_mac
Flash tasmota (tasmota.bin from the releases page)
esptool -p /dev/ttyUSB0 --chip esp8266 -b 74880 write_flash -e -fs 1MB -fm dout 0x0 tasmota.bin

The Living Patient

It’s go time.

Now that I can directly flash the sacrificial device, it’s time to set up the one I hope to save.

Even knowing I was communicating with the ESP correctly, I wasn’t particularly excited about holding jumper wires in place. I realized I could reduce the number of wires I needed by one if I could connect to the mains neutral instead of the ESP’s ground contact, which worked. I also decided to use hot pins to poke through the plastic, since sufficiently precise pin placement would mean minimal manual holding.

The only ESP module information I could find gave exactly one relevant measurement, that the edge connector was 16.4mm. Calipers provided the rest³.

Based on these measurements, I needed pins at the following locations:

pin	mm from plug end	mm from ground side
GPIO0	22.45	5.65
UTXD	27.50	7.90
URXD	27.50	5.65
VCC	30.02	5.65

Lastly, GND connects to neutral, the flat prong farther from the button.

I measured with calipers, marked the grid with a knife, held each pin with pliers above a lighter to heat them until they glowed, and stuck them straight down at each location.⁴

One ended up a bit off-vertical, so I bent the pin in the other direction and reinserted it. Two more had plastic or soot on the tip, so those needed to be pulled, cleaned, and reinserted. Finally, with all the leads attached and gentle pressure on the pinheads…

ets Jan 8 2013,rst cause:1, boot mode:(1,0)

It lives! Disconnect picocom, run esptool, and…

Wrote 473856 bytes (328288 compressed) at 0x00000000 it 44.8 seconds (effective 84.6 kbit/s)...
Hash of data verified.

Pull the pins off, plug it in, and!

Conclusion

I spent several afternoons saving a $5 smart outlet. And then too long (in both words and time) writing it up, but I’m trying to document more stuff I do on the off chance some part of it ends up being useful to someone. Half the time that someone is just me, six months later.

This is probably also not the best idea from a standpoint of not lighting things on fire - it’s doing things that weren’t meant to be done to a device that controls up to 20 amps at 120 volts. Your device may also not be identical to mine. Attempting to follow these steps may break your smart outlet, make it burn your house down, or call your dog a bad girl, and I accept no responsibility for any of it.

It pretends to work fine, but forgets its settings about once a week. Useful for this, since I can test flashing but don’t feel bad about destroying it. ↩︎
If you don’t have the right tool handy, just go find it. ↩︎
1.25mm plastic wall above ledge, 3mm plug side board inset, 10mm from board edge to ESP module connector edge, 20.85mm from ESP module other end to other board end, 4mm button side board inset, 1.25mm wall. Sum of 56.75mm, measured size is 57mm - not bad. From the ground side, 1.25mm wall, 1.65mm board inset, module 2.75mm from board edge. ↩︎
No blood sacrifice was demanded at this step, but I still should have gone and dug out the pliers before the first mild burn. ↩︎