Actually, including seconds, it is January 1, 1981 1:01:02.

brenton@Brentons-Pieces-M3-MacBook-Pro spacehockey % ls -alT app/build/outputs/apk/release/app-release/ 
total 2944
drwx------@  14 brenton  staff      448 Feb 23 16:20:36 2026 .
drwxr-xr-x@   7 brenton  staff      224 Feb 23 16:19:43 2026 ..
-rw-r--r--@   1 brenton  staff     6148 Feb 23 16:20:36 2026 .DS_Store
-rw-rw-r--    1 brenton  staff    10572 Jan  1 01:01:02 1981 AndroidManifest.xml
drwxr-xr-x   25 brenton  staff      800 Feb 23 16:19:43 2026 assets
-rw-r--r--    1 brenton  staff  1342700 Jan  1 01:01:02 1981 classes.dex
-rw-rw-r--    1 brenton  staff     1738 Jan  1 01:01:02 1981 DebugProbesKt.bin
drwxr-xr-x    3 brenton  staff       96 Feb 23 16:19:43 2026 google
drwxr-xr-x    3 brenton  staff       96 Feb 23 16:19:43 2026 io
drwxr-xr-x    9 brenton  staff      288 Feb 23 16:19:43 2026 kotlin
drwxr-xr-x    6 brenton  staff      192 Feb 23 16:19:43 2026 lib
drwxr-xr-x   44 brenton  staff     1408 Feb 23 16:19:43 2026 META-INF
drwxr-xr-x  266 brenton  staff     8512 Feb 23 16:19:43 2026 res
-rw-rw-r--    1 brenton  staff   138724 Jan  1 01:01:02 1981 resources.arsc

That is a peculiar date time! I can imagine that the tooling for APK files would want to timestamp all files with a consistent date time for security and build reproducibility. And I can even imagine that filling all fields (year, month, day) and (hour, minute, second) with 1 would be a good date time to use.

But the second value is 2 and not 1. What is going on?

After some searching, I found this issue:

Incorrect timestamp when unzipping universal apk

The comments in that issue confirm that this is intentional behavior, but the question remains: why this particular date time?

I looked through the sources of bundletool and found this line:

private static final long ZIPFLINGER_ZIP_TIMESTAMP = 347158862000L;

January 1, 1981 1:01:02 is 347158862 seconds since January 1, 1970.

Fine. So it seems like something called ZipFlinger is doing the actual timestamping of files in the APK and that is where January 1, 1981 1:01:02 is coming from.

More searching. Find Zipflinger.

From the docs:

Zipflinger is a library dedicated to ZIP files manipulation. It can create an archive from scratch but also add/remove entries without decompressing/compressing the whole archive.

Looking through the sources for Zipflinger, I find:

// JDK 9 consider time&data field with value 0 as invalid. Use 1 instead.
// These are in MS-DOS 16-bit format. For actual specs, see:
// https://msdn.microsoft.com/en-us/library/windows/desktop/ms724247(v=vs.85).aspx
public static final short DEFAULT_TIME = 1 | 1 << 5 | 1 << 11;
public static final short DEFAULT_DATE = 1 | 1 << 5 | 1 << 9;

Aha!

The date and time values are 16-bit shorts that set 1 bits at particular locations.

What is MS-DOS 16-bit format ?

We can see here that MS-DOS dates look like this:

0000001000100001
           ^~~~~
           day of month
       ^~~~
       month
^~~~~~~
year offset from 1980

and MS-DOS times look like this:

0000100000100001
           ^~~~~
           second / 2
     ^~~~~~
     minute
^~~~~
hour

Interesting! MS-DOS time has resolution of 2 seconds.

That explains the strange 1:01:02 time from the beginning. January 1, 1981 1:01:02 is the date time you get when all fields in MS-DOS date time are filled in with 1s.

Elevator pitch

Imagine that you are sitting at a table with friends, like in a dining room or at a bar. You lay your mobile devices side-by-side and start playing a game.

Something like Air Hockey or Breakout being played across the screens of your devices.

This is Space Hockey, and it’s what I’ve been working on.

My vision

Inspired by the multiplayer games of my youth, I want to create a new kind of gaming experience.

Everyone has a mobile device nowadays.

Our mobile devices are physical artifacts in the real world.

Why not use the physical aspects of our devices for gaming?

I want a new kind of game.

Ad-hoc and spontaneous.

The games are impromptu and are different depending on which devices are used.

Devices are different shapes and sizes and every combination is different.

But more than a single game, I want to make a platform, a platform for mobile-first gaming.

Details

How do the devices connect?

How do games look good across screens with different resolutions?

How many different devices can be connected? 2? 3? more?

These are all problems that need to be solved and I am solving them.

An insane amount of engineering has been done to ensure that games work in hostile Wi-Fi environments.

Timeline

Like how Doom and Quake were fun games and impressive tech demos, I want Space Hockey to be a fun game and an impressive tech demo.

I am slowly releasing milestones of Space Hockey.

The current plan is to release the simplest thing that can work: Android only, 2 devices, same Wi-Fi network.

After the actual Android release, there will be an iOS release, and perhaps other platforms like Windows.

Then there will be work to not require an existing Wi-Fi network, and instead have devices talk directly to each other with Wi-Fi Aware.

And then of course, supporting more than 2 devices.

Check it out!

I have a channel where I post milestones: https://www.youtube.com/@haltingsoftware

I also want in-person play testing, so email me at haltingsoftware@gmail.com if you want to be added to the Google Play internal testing group for Android.

Background

I was looking through Wikipedia’s list of time formatting and storage bugs when I noticed an entry for December 2024:

In December 2024, a 30-year-old bug was found in all versions of HCL Notes. When the server is started on or after December 13, 2024, an overflow would prevent the mail router from loading its configuration, and so no mail is delivered. Patches were released on the next day for all supported versions.

With a reference that goes here:

CRITICAL ALERT: Mail not routing after Domino restarts beginning December 13, 2024

The page mentions:

The date/time issue made the TimeDateDifference() internal call return incorrect results under certain conditions, and dates back to the core Notes program in 1986.

But no actual root cause analysis is provided.

A common source of date / time bugs is overflow, where the date or time eventually grows too large to be contained by its storage, and is then treated as negative or as an error.

I wonder if what happened on December 13, 2024 was an overflow problem or something else?

Interesting. I have been nerd-sniped.

Initial research

I do not have a copy of Notes or Domino to reverse-engineer and it is unlikely that I will get copies. I must work through public sources of information.

What is the TimeDateDifference function that is mentioned in the alert?

Here is its documentation:

https://opensource.hcltechsw.com/domino-c-api-docs/reference/Func/TimeDateDifference/

#include <misc.h>
LONG LNPUBLIC TimeDateDifference(
    const TIMEDATE far *t1,
    const TIMEDATE far *t2);

And documentation for the TIMEDATE struct is here:

https://opensource.hcltechsw.com/domino-c-api-docs/reference/Data/TIMEDATE/

typedef struct tagTIMEDATE {
   DWORD Innards[2];
} TIMEDATE;

Hmmm, no real documentation for the structure of TIMEDATE.

More research

There are other date / time related support pages from HCL:

Error “Unable to interpret time or date” when entering specific dates from the year 1752

There is special handling for invalid dates in the Gregorian Calendar.

Maybe the bug is related to the year 1752 and Gregorian calendar?

The number of seconds from September 1752 to Dec 13 2024 is roughly 2^33, but the days don’t line up with anything significant.

Some Wolfram Language code:

In[1]:= FromUnixTime[UnixTime[{2024, 12, 13}] - 2^33]

Out[1]= Fri 29 Sep 1752 11:03:28GMT-4

(The functions UnixTime and FromUnixTime are a convenient way to convert between dates and seconds.)

The coincidence of September 1752 and 2^33 seconds is tantalizingly close, but not close enough for my liking.

2^33 is not likely to be significant to date / time code from the 1980s and September 29 1752 has no actual significance.

Maybe related to Michaelmas?

In the mean time

I left a comment on HCL’s Community forum for the December 13 bug:

https://support.hcl-software.com/community?id=community_blog&sys_id=4a7f878047a69e5033723c5c716d4379

But did not receive a reply from HCL.

I also sent an email to Origina but did not receive a reply.

More research

A breakthrough!

Daniel Nashed’s excellent blog explained several things:

Notes Timedate explained

TIMEDATE uses Julian Dates.

OK, some things are making sense.

Julian Dates start counting from January 1, 4713 BC (Julian Calendar).

We do not know the exact time that the problem occurred, so let’s look at the Julian Dates for December 13 and December 14 and see if anything interesting happens between them.

In[2]:= Block[{$TimeZone = 0},
           Floor[JulianDate[{2024, 12, 13, 12, 0, 0}]]
         ]

Out[2]= 2460658

In[3]:= Block[{$TimeZone = 0},
           Floor[JulianDate[{2024, 12, 14, 12, 0, 0}]]
         ]

Out[3]= 2460659

The Julian Date for December 13, 2024 is 2460658.

The Julian Date for December 14, 2024 is 2460659.

The number of seconds since the Julian Date epoch to December 13, 2024:

In[4]:= december13JulianSeconds = 2460658 * 24 * 60 * 60

Out[4]= 212600851200

The number of seconds since the Julian Date epoch to December 14, 2024:

In[5]:= december14JulianSeconds = 2460659 * 24 * 60 * 60

Out[5]= 212600937600

What are these values in binary?

In[6]:= IntegerString[december13JulianSeconds, 2]

Out[6]= 11000101111111111111111000101100000000

In[7]:= IntegerString[december14JulianSeconds, 2]

Out[7]= 11000110000000000000001101110010000000

Wait. It looks like a lot of bits get flipped when going from December 13 to December 14.

These values are 38 bits. What are the values when truncated to 32 bits?

In[8]:= IntegerString[212600851200, 2, 32]

Out[8]= 01111111111111111000101100000000

In[9]:= IntegerString[212600937600, 2, 32]

Out[9]= 10000000000000001101110010000000

Ah ha!

The MSB is flipping from 0 to 1 when counting seconds from December 13 to December 14.

Everything makes sense now.

My current hypothesis:

On December 13, 2024 at 8:19:12am (29952 seconds after midnight), the number of seconds since the Julian Date epoch flipped from being positive to being negative in signed 32-bit storage.

Accidentally treating time as negative is a classic cause of date / time bugs.

I hesitate to say “overflow” because it first overflowed January 19, 4645 BC (Julian calendar) and after that, every ~68.1 years, has been alternating between being stored as positive and being stored as negative.

In[8]:= 2^31 / 60 / 60 / 24 / 365 // N

Out[8]= 68.0963

We just happened to be in a window of ~68.1 years where the time was stored as positive.

The previous flip was November 25, 1956, where dates flipped from negative to positive.

This flip was December 13, 2024, where dates flipped from positive to negative.

The next flip will be December 31, 2092, where dates will flip from negative to positive again.

This is the same problem as the upcoming Year 2038 problem, just shifted.

Counting the number of seconds from January 1, 1970 will get to January 19, 2038 before flipping from positive to negative in signed 32-bit storage.

January 19, 2038 will be the first flip since the Unix epoch. But December 13, 2024 was the 99th flip since the Julian Date epoch!

FYI, the FromUnixTime and UnixTime functions from above use arbitrary-precision numbers and do not run into the 32-bit limitations discussed here.

As long as the arguments to TimeDateDifference are in the same positive window (e.g., between November 25, 1956 (after the flip) and December 13, 2024 (before the flip)), then TimeDateDifference probably works fine. This is probably what the critical alert meant when it said:

The date/time issue made the TimeDateDifference() internal call return incorrect results under certain conditions, and dates back to the core Notes program in 1986.

But I am surprised that it took until the actual flipping date to notice the problem. Apparently no dates before and after December 13, 2024 were ever differenced. Or maybe they were and nobody noticed?

Summary

With minimal information, we were able to figure out what happened on December 13, 2024 with high likelihood.

There was a massive red herring to do with September 1752 and the switch to the Gregorian Calendar. But that is part of the fun of figuring these things out.

Ultimately, the number of seconds from the Julian Date epoch flipping signs in signed 32-bit storage every ~68.1 years explains the problem satisfactorily.

This was my first CTF and I think that it was a good introduction to these kinds of events.

A lot of the challenges were straightforward.

I completed Shuffle, Chalkboard and had started to sink my teeth into the Sage challenge, when I came back the next morning to find that there was a message saying that the Sage, Outpost, MSS-Advance, Shuffle, and Chalkboard challenges had been removed.

This was frustrating because of the wasted time spent on solved challenges.

I had even started progress on Sage, but oh well:

• LatticeHacks

• Factoring a RSA modulus given parts of a Factor

I really only worked from March 7 to March 11 and I got rank 710.

I was working on the Echo Valley challenge, but I could never get the return address correctly overwritten. Probably related to ASLR.

Here are the release notes:

• Added options for emitting ControlChange events, ProgramChange events, and PitchBend events

Here are the release notes:

• Tablature can now be printed
• Muted notes
• Track volume is exported using CC7, instead of note velocity
• Custom Lyric events may be used to trigger callbacks in FluidSynth
• Fix wall clock time formatting and better midi file info
• Lots of small improvements

Release notes:

• Two-finger pinching can be used to change the font size in the Open/Help/Rule screens.
• Fixed a problem with the Open screen’s font size being too large on small devices.
• Fixed an error that prevented Rule info from being displayed.
• Fixed a bug that could prevent pasting into a bounded grid.
• Most links in Help > Online Archives and References should now work (some will fail if using Android 7 or older).
• Supplied patterns no longer include .lua/zip/rle3 files.

Over the last several weeks, I have been working with Andrew Trevorrow to update the Android build of Golly.

Bit rot is real, and can be easily seen by trying to open an Android Studio project that has not been updated for a few years.

I have updated everything in the Android Studio project and even fixed a few bugs along the way.

1*^-1355718576299609

and after ~90 seconds, a broken page was returned.

This is most likely because the underlying Wolfram Language kernel process crashes due to memory exhaustion.

Relatedly, I entered this input into Wolfram|Alpha:

1.0`90071992

and after ~15 seconds, a page was returned saying:

Interpreting as: 90071992

This is odd, because the notation 1.0`90071992 is WL notation for specifying 1.0 with 90071992 digits of precision.

Both of these results are odd, but the first is more severe because it may be used in a denial-of-service attack against Wolfram|Alpha.

Following responsible disclosure

On Tues Feb 13 2024, I sent:

I have found inputs that make Wolfram|Alpha seemingly hang or become unresponsive, which could be used in a DoS attack.

This is because of the nature of Real number parsing in Wolfram Language where numbers such as:

1*^-1355718576299609

1.0`90071992

will take HUGE amounts of memory.

And this happens during parsing, before any evaluation takes place.

With these inputs, I have seen W|A hang for ~90 seconds and just return junk.

Care must be taken to handle these exceptional cases.

It seems that the input 1*^1355718576299609 is handled correctly, so perhaps whatever mechanism is already handling that could be made to handle the Rational case above.

And Real numbers could be scanned for too large precision before proceeding.

Brenton
(former Wolfram employee)

and received this automated response:

I waited 90 days for a response or at least a fix to Wolfram|Alpha. Neither happened, so I am publicly disclosing the issue now.

Background

Wolfram Language has arbitrary-precision number literals built into the language.

Other languages, such as Java and Python, also have arbitrary-precision numbers, but do not have a literal syntax for them.

Wolfram Language syntax is very complex, but the gist is that these 3 digits in the precision:

In[1]:= 1`100

Out[1]= 1.0000000000000000000000000000000000000000000000000000000000000000000000000000\
000000000000000000000000

give an output with 100 digits of precision.

And these 3 digits in the exponent:

In[107]:= 1*^100

Out[107]= 100000000000000000000000000000000000000000000000000000000000000000000000000000\
00000000000000000000000

give an output with 100 digits.

The size of the output depends on the value of the given precision or the exponent.

We can make small inputs turn into very large outputs. This is important to understand.

The memory use is proportional to the value of the specified precision, so increasing the size of the input by 1 byte results in ~10x increase in memory use, increasing the size of the input by 2 bytes results in ~100x increase in memory use, etc.

Continuing to increase the size of the input even more will consume much, much more memory.

A specially-crafted input may exhaust system memory, cause WL-specific SystemExceptions to be thrown, or to crash the kernel.

No evaluation, only parsing

Wolfram Languages’s input syntax for real numbers allows large amounts of memory to be consumed, even before any evaluation has occurred.

Here is a demo in Mathematica:

In[1]:= MaxMemoryUsed[ToExpression["1.0`123456789;ignore", InputForm, Hold]]

Out[1]= 102536464

The 13 bytes input 1.0`123456789 consumes ~100MB of memory.

The ignore is to ensure that the result does not leak out as a return value in any way and the Hold is to ensure that the input is not evaluated.

Because this attack is reminiscent of Zip bombing, I am naming this attack Precision Bombing.

Precision Bombing (and Exponent Bombing)

In Mathematica 13.2:

% /Applications/Mathematica132.app/Contents/MacOS/WolframKernel 
Mathematica 13.2.0 Kernel for Mac OS X ARM (64-bit)
Copyright 1988-2022 Wolfram Research, Inc.

In[1]:= ToExpression["1.0`900719925474099"];                                                                                            

General::nomem: The current computation was aborted because there was insufficient memory available to complete the computation.

Throw::sysexc: Uncaught SystemException returned to top level. Can be caught with Catch[..., _SystemException].

Out[1]= SystemException[MemoryAllocationFailure]

In[2]:= 

So some very large input such as 1.0`900719925474099 is handled internally.

What about a smaller but still very large input?

% /Applications/Mathematica132.app/Contents/MacOS/WolframKernel 
Mathematica 13.2.0 Kernel for Mac OS X ARM (64-bit)
Copyright 1988-2022 Wolfram Research, Inc.

In[9]:= ToExpression["1.0`90071992547"];                                                                                                
zsh: killed     /Applications/Mathematica132.app/Contents/MacOS/WolframKernel
% 

I had to manually kill the WL kernel process after it tried taking 40+ GB of memory.

Similarly, we can try an input with a large exponent:

% /Applications/Mathematica.app/Contents/MacOS/WolframKernel 
Mathematica 13.0.1 Kernel for Mac OS X x86 (64-bit)
Copyright 1988-2022 Wolfram Research, Inc.

In[1]:= 1*^1355718576299610                                                                                                                                                                    

General::ovfl: Overflow occurred in computation.

Out[1]= Overflow[]

This is handled fine by Mathematica because it is larger than $MaxNumber:

In[19]:= $MaxNumber

Out[19]= 1.605216761933662*10^1355718576299609

What about a smaller but still very large input?

% /Applications/Mathematica.app/Contents/MacOS/WolframKernel
Mathematica 13.0.1 Kernel for Mac OS X x86 (64-bit)
Copyright 1988-2022 Wolfram Research, Inc.

In[1]:= 1*^1355718576299609

zsh: killed     /Applications/Mathematica.app/Contents/MacOS/WolframKernel

I had to manually kill the WL kernel process after it tried taking 5+ GB of memory.

Details

Let’s look at memory usage of parsing numbers as we increase the exponent.

In[8]:= data1 = Table[{x, 
     MaxMemoryUsed[ToExpression["1*^" <> ToString[x] <> ";ignore"]]}, {x, 
     200000, 1000000, 100}]; // AbsoluteTiming

Out[8]= {14.5374, Null}

In[9]:= ListPlot[{data1}, Joined -> True]

Out[9]= ...

Looks roughly like a line. Let’s fit it:

In[10]:= line = Fit[data1, {1, x}, x]

Out[10]= 24029.8 + 1.20732 x

In[11]:= ListPlot[{data1, {#, line /. x -> #} & /@ data1[[All, 1]]}, Joined -> True, 
 PlotLegends -> {"data", "fit"}]

Out[11]= ...

So the memory needed seems to be a function 1.2 * exponent and this makes sense. The theoretical limit is the number of bytes needed to store a decimal digit:

In[12]:= Log2[10]/Log2[8] // N

Out[12]= 1.10731

and there are various internal overheads.

So trying to parse these 19 bytes:

1*^1355718576299609

will require 1.2*1355718576299609 == 2^50 bytes == 10^6 GB of memory

Using 10^6 GB of memory from 19 bytes of input is a pretty good ROI!

Now let’s look at memory usage of parsing numbers as we increase the precision.

We will parse numbers like 1.0`1000000000 and then call MaxMemoryUsed[] after each number.

In[8]:=
precs = {
   1000000000,
   2000000000,
   3000000000,
   4000000000,
   5000000000,
   6000000000,
   7000000000,
   8000000000,
   9000000000
   };
data = {};
Do[
 max = MaxMemoryUsed[ToExpression["1.0`" <> ToString[prec] <> ";ignore"]];
 AppendTo[data, {prec, max}]
 ,
 {prec, precs}
 ]

Hopefully this is a line:

In[13]:= ListLinePlot[data]

Out[13]= ...

In[14]:= line = Fit[data, {1, x}, x]

Out[14]= 7915.56 + 0.830482 x

It looks like about 0.83/byte is used for precision specification.

In[15]:= bytesPerPrecDigit = line[[2]] /. x -> 1

Out[15]= 0.830482

In[16]:= bitsPerPrecDigits = 8 bytesPerPrecDigit

Out[16]= 6.64386

But where does 0.83 comes from? The entropy of decimal digits:

In[17]:= bitsPerDigit = Log[2, 10] // N

Out[17]= 3.32193

3.32193 is the theoretical limit of number of bits for decimal digits.

In[19]:= bitsPerPrecDigits/bitsPerDigit // FullForm

Out[19]//FullForm= 2.000000000669874`

It seems like precision specification is a very neat factor of 2 above that theoretical limit.

The factor of 2 is most likely because the Wolfram Language kernel is making a copy of the number somewhere internally.

Verdict

In this DoS attack, memory is consumed when the input is being parsed. No evaluation needs to occur for this attack to work.

Systems that use Wolfram Language to process user input are susceptible to a DoS by malicious users supplying input such as 1*^-1355718576299609 and 1.0`90071992 to crash the WL kernels that process the input.

Mitigations would involve scanning input that uses *^ or precision syntax and warning if exponents or precision are above some large limit, say 10*^6 for exponents and 10*^7 for precision