May I remind you of the fact that the inductive loads have a massive inrush current...

Which means a massive magnetic field...

Which, to unprotected devkits in your switchboards with coiled up Dupont wire right next to these AC lines means...

Massive spikes in voltage... What do they do to poor tiny ESP32s and the input pins on relays?

They kill them. Straight up murder, let me tell you! Guess who learnt it the hard way?

Expensive mistakes :(

The fact that my ESP32s survived almost 4 years is a massive achievement, but yeah they're slowly starting to die. I guess I'll have to shield them.

Or just get a ZBMINI from Sonoff and get those ESP32s off the damn Wi-Fi network. Frankly, I might just do that.

Thanks for reading...

The Backstory

Earlier this year, I was debating over getting either a Casio CG-50 or a TI-Nspire for my AP Calc BC exam. To me, the ability to mod and mess around with my stuff is an important factor, and upon a quick google search, the Nspire had ndless, which allowed me to run assembly programs. Hence obviously, I purchased the Nspire.

To my dismay, however, my calculator was too new to run ndless(it shipped with OS ver. 6.0). Unfortunately, the project seemed abandoned, with no updates in over 4y. Desperate, I started looking for exploits myself, hoping to port it. Eventually, I was added to the dev group, and Ndless r2020 was born.

My drive for digging into the calc didn't end there, however. I eventually discovered that Firebird, the emulator for all Nspires, couldn't emulate the CX II. "Incomplete bootrom detected.", it would complain. Intrigued, I looked into what exactly this "incomplete" meant, and it turned out to be this hidden region of the BootROM from 0x27800 to 0x28000, which was nicknamed keys.

While most of BootROM is normally readable and dumpable using a tool such as polydumper, this elusive region will dump out all zeros. It was understood that it would only be unmasked under a very specific set of conditions, conditions only known to TI and etched into the silicon.

The Analysis

By disassembling the dumped BootROM using Ghidra, is it quite trivial to find out that function 0x39C is responsible for reading the keys. However, it directly loads the keys into the 3DES MMIO block. The keys never touch SDRAM!

It is obvious that there is some sort of check on the Program Counter(PC), since both the OS and the Bootloader never attempt to read that region by themselves. Instead, they call 0x150(which eventually calls 0x39C) to directly load the keys to 0xC8010000, the location of the 3DES MMIO block. They then use it directly to encrypt and decrypt the files. This is a direct indicator that keys can only be read from BootROM, and maybe only specifically those instruction addresses.

Furthermore, according to research done by Vogtinator, the hardware is needed to be in an extremely specific state. MMU needed to be off and some undocumented bits in CP15 needed to be set. The 3DES engine seems have its registers be write-only, and reading would only produce 0x5D5AEA97(not keys). All to say, TI did not cheap out on the security... Or did they...?

Wait a second...

While stepping through the instructions in Firebird(which could at max load bootloader without keys), I noticed something odd. The stack pointer was assigned to 0x1800FB54. This address does not exist in physical memory, since SDRAM is only from 0x10000000 to 0x14000000. This meant that the MMU was actively in use. This contradicted with what Vogtinator said previously so I checked it out myself:

A multi-billion dollar company such as TI could surely have foreseen that if the MMU is on, it is extremely simple to do some MMU mapping shenanigans to hijack where keys are written. Obviously, right?

This is a funny pattern that I've noticed across the entire Nspire code. TI seems to fortify their house with bricks but leaves their front door wide open. Of course, there could still be a check to ensure that 0xC8000000 was identity mapped, but you are reading this post so you know where that is going :D

Looking at my (admittedly very ugly) code for the exploit, the starting just creates the program's own page tables so I can freely change memory mappings.

uint32_t pt_addr = ((uint32_t)page_table_buffer + 0x3FFF) & ~0x3FFF;
uint32_t *page_table = (uint32_t *)pt_addr;

It goes on to identity map most peripherals, SRAM and RAM. However, with regards to 0xC8000000:

uint32_t des_va_idx = 0xC8000000 >> 20;
page_table[des_va_idx] = (0x13000000 & 0xFFF00000) | (0b11 << 10) | (0 << 5) | 0 | 0b10;

This maps 0xC8000000 to 0x13000000, so any writes to the 3DES engine ends up at 0x13010000. Therefore, after somehow exiting from 0x39C, we can just read off this address to get keys.

The Stack Trap

When I originally attempted to call 0x39C, it would not return only on hardware. Therefore, I though I could exploit this piece of code:

0000076c 60 10 8f e2     adr        r1,DAT_000007d4  = E12FFF1Eh
00000770 00 40 91 e5     ldr        r4,[r1,#0x0]=>DAT_000007d4  = E12FFF1Eh
00000774 10 00 2d e9     stmdb      sp!,{r4}
00000778 3d ff 2f e1     blx        sp

For some reason, it attempts to load a bx lr into the stack and jump to it. I don't exactly understand why, but this is before

00000788 b3 fe ff eb     bl         FUN_0000025c 

which was causing the problems with not returning. Hence, by setting the stack to an extremely precise position at the edge of accessible memory, it is possible to get back control right after keys are read a couple instructions earlier. For this, I create my own exception vectors:

uint32_t vec_addr = ((uint32_t)vector_buffer + 0xFFF) & ~0xFFF; 
uint32_t *vectors = (uint32_t *)vec_addr;

uint32_t cpta_vec_addr = ((uint32_t)cpta_vectors_buffer + 0x3FF) & ~0x3FF;
uint32_t *coarse_vec_table = (uint32_t *)cpta_vec_addr;

// build vector table
printf("Setting up vector table at 0x%08lX...\n", vec_addr);
for (int i = 0; i < 8; i++) vectors[i] = 0xE59FF018;
vectors[12] = (uint32_t)data_handler; // The one we care about

And map it to 0xFFFF0000 . I also enable high vectors, so the ARM CPU knows to jump to my vectors instead of BootROM's:

// high vector enable
uint32_t sctlr;
asm volatile("mrc p15, 0, %0, c1, c0, 0" : "=r"(sctlr));
sctlr |= (1 << 13) | (1 << 0);
asm volatile("mcr p15, 0, %0, c1, c0, 0" :: "r"(sctlr));

Setup

Next, we perform some setup for the exploit:

void perform_exploit_setup(void) {
    printf("Performing exploit setup...\n");

	// these are the observed conditions that 0x39c is in when called via bootloader.
	volatile uint32_t *usb_top = (volatile uint32_t *)0xB0000000;
	usb_top[0x100 / 4] = 0;

	usb_top[0x1C0 / 4] = 0;

	// extensive setup, refer to the source for the full function

    printf("Exploit setup complete.\n");
}

This is just setting a list of conditions on the hardware(such as shutting off the DMA, the USB controllers etc) that the CPU expects at this point. Without this, the CPU will just return 0x0s. Most of this was just observed by using Firebird. Finally, we can call trigger_next_key();, which just jumps into SVC mode(in case we were previously in abort mode), resets the trap stack(which catches the stmdb at 0x774) and jumps to call_rom39c.

0x39C takes in 4 paramters. r0 is ignored and overwritten. r1just dictates which part of the switch will be used(we want 0x5), r2 decides which "set" of keys we are loading and r3 sets the 3DES engine to either encrypt or decrypt mode. By iterating r2 for each call, we can extract the entire hidden region. However, it seems like only 0x27, 0x3d, 0x25, 0x2d are ever used. Hence, my program only extracts those:

__attribute__((naked))
void call_rom39c(uint32_t __attribute__((unused)) sram_stack, uint32_t __attribute__((unused)) r2_val) {
    asm volatile(
        // r0 = sram_stack
        // r1 = r2_val
        
        "mov r12, r0                \n\t"   // r12 = sram_stack
        
        // Save caller registers on *current* stack
        "stmfd sp!, {r4-r11, lr}    \n\t"

        // Save old SP
        "mov   r4, sp               \n\t"

        // Switch to trap stack
        "mov   sp, r12              \n\t"

        // Save old SP on trap stack
        "stmfd sp!, {r4}            \n\t"

        // Setup ROM args
        "mov r2, r1                 \n\t"   // r2 = r2_val
        "mov r0, #0x5               \n\t"
        "mov r1, #0x5               \n\t"
        "mov r3, #0x1               \n\t"

        // Call ROM 0x39C
        "ldr lr, =0x0000039C        \n\t"
        "blx lr                     \n\t"

        // Restore SP
        "ldmfd sp!, {r4}            \n\t"
        "mov   sp, r4               \n\t"

        // Restore caller registers and return
        "ldmfd sp!, {r4-r11, lr}    \n\t"
        "bx lr                      \n\t"
    );
}

The Finale

Here's the final flow:

1. We call 0x39C
2. It writes keys to what it thinks is 0xC8010000
3. The keys end up at 0x13010000
4. CPU attempts to stmdb, and ends up in our no-access region
5. DATA ABORT!

This calls our own exception vectors, which copy the keys to a different location and moves onto the next set of keys:

void c_handler(EXCEPTION_TYPE type, uint32_t lr, uint32_t sp) {
    if (type == DATA_ABORT) {
        volatile uint32_t* des_regs = (volatile uint32_t*)0x13010000;
        for (int i = 0; i < 6; i++) {
            extracted_keys[current_key_idx][i] = des_regs[2 + i];
        }

        // ... print keys ...
        current_key_idx++;
        trigger_next_key();
    } else {
        // ... error handling ...
}

After all keys are extracted, we can display the keys to the user. I have chosen to do this via a QR code, allowing the user to easily use a tool to inject keys into their keyless bootrom.

(It seems like there's some sort of issue with my nginx reverse proxy and https, causing the above image to not load in correctly. You might need to click on it.)

Both QRs are the same, this is just the result of weird VRAM mapping that TI does and me being too lazy to handle it correctly. Furthermore, since this program messes up the state of the device pretty bad, I found it easier just to reset instead of attempting to restore and exit back to the Nspire UI.

And there you have it. (some of) the TI-Nspire CX II's security is broken with an UNPATCHABLE exploit. Good job TI :)

I'd appreciate if you could star the project on Github below

Exploit: https://github.com/satyamedh/eMMUlate
Injector: https://satyamedh.github.io/eMMUlate_injector

I've discovered MediaTek's chips suck ass. Be it the RZ616 on my fw13 or the RZ608 on my Asus ROG motherboard, I keep running into this bullshit where bluetooth just dies and I have to shut down and wait to get this fixed. Screw MediaTek :D

Thanks for reading :)

Have soil that needs to be monitored but has no access to an electricity line or Wi-Fi? My project here might just be a great solution for you!

The frustration is real: you want to give your plants the best chance to thrive, but manual checks are time-consuming, and traditional smart garden tech often falls short in remote areas. Limited by power outlets and Wi-Fi range, many promising solutions are simply impractical for sprawling gardens or off-grid plots.

That's where my project comes in. This prototype, using an ESP32, SX1278 LoRa transceiver, and a bunch of sensors, allows you to monitor your farm, garden, or even just a little plant anywhere. It is designed to be used from as small as just one node, to be scaled to a huge farm. Imagine having accurate, real-time data about your soil's moisture, temperature, Carbon Monoxide levels, all delivered reliably, even in the most remote corners of your land. Intrigued? Let's dive deeper into how this works.

LoRa: Beyond Wi-Fi and Wires

Traditional garden monitoring solutions often hit a wall – literally. Wi-Fi has limited range, struggles with obstacles, and typically requires a constant power source. Running wires across a large garden or farm is simply not feasible. This leaves many aspiring smart gardeners out in the cold, or rather, out in the unmonitored field.

This is precisely why I designed a system that leverages LoRa (Long Range) technology, for my project. LoRa allows for incredible communication distances with very little power, making it perfect for remote locations where traditional Wi-Fi can't reach.

But what happens if a single sensor is too far even for LoRa to reach the main hub directly, or if there are obstacles in the way? That's where a clever feature comes in: packet re-broadcasting. Imagine your garden sensors as little messengers. Each sensor sends out its data, and if a neighboring sensor hears that message but doesn't receive an acknowledgement from the receiver, it simply repeats it, helping the information travel further across your garden. This way, even if a sensor is tucked away behind a shed or far down a field, its data can still make its way to the central monitoring station by "hopping" through other nearby sensors. In the future I plan on completely converting this into a mesh-based network with route planning etc.

For agriculture, this means:

• Unparalleled Range: LoRa allows for communication over 8-10 kilometers, making it perfect for large farms or gardens where Wi-Fi signals simply wouldn't reach.
• Ultra-Low Power: LoRa is incredibly power-efficient, allowing our sensor nodes to run for extended periods on basic AA batteries, completely liberating them from the need for external power lines. This is crucial for off-grid operations.

By leveraging LoRa with this intelligent re-broadcasting, we're not just adding smart tech to your garden; we're fundamentally rethinking how we monitor natural environments, making it accessible and reliable, even in the most challenging locations.

What Does It Monitor?

So, what exactly does this powerful, off-grid system tell you about your plants? My prototype is designed to capture the vital signs of your soil and immediate environment, providing actionable insights right to your fingertips.

Currently, each sensor node in the system gathers critical data points:

• Soil Moisture: This is arguably the most crucial metric. My sensors tell you exactly how much water is available to your plants in the soil. No more overwatering, no more under-watering – just optimal hydration. You'll know precisely when your plants are thirsty, and when they've had enough. It is possible to integrate this with an automated system to make watering automatic even!
• Ambient Temperature: Understanding the air temperature around your plants is key for growth and preventing stress. Sudden drops or spikes can indicate a need for protection or adjustment.
• Humidity: High or low humidity can affect plant transpiration and disease susceptibility. Monitoring this helps you create the ideal microclimate for your crops.
• Carbon Monoxide (CO) for Early Detection: While primarily focused on plant health, we've also integrated a Carbon Monoxide sensor. Beyond being a danger to humans, sudden increases in CO can be an early indicator of smoke or smoldering in the area. My system processes this CO data to help detect potential fire incidents quickly, providing an extra layer of peace of mind for your valuable crops and property.

To ensure all sensor readings are accurately time-stamped and synchronized across your garden, the system also uses a small NEO-6M GPS module for precise time synchronization. This helps in organizing and analyzing data chronologically, giving you a clear historical view of your garden's conditions.

All this data, collected wirelessly and efficiently by our sensor network, is then transmitted to a central gateway. From there, it's pushed to a robust backend, which can be adapted to any frontend you desire (for example, a Home Assistant server). I've developed a sample Home Assistant backend to demonstrate the capabilities, but the system is designed for flexibility, allowing integration with various monitoring dashboards.

Aaaand what about power?

Don't worry, I kept that in mind too. Utilizing the advanced deep sleep modes of the ESP32 microcontroller and the LoRa SX1278 transceiver, the sensor nodes spend most of their time in a low-power state, only waking up when necessary to take readings and transmit data. Components like the GPS module and the MQ7 CO sensor, which consume more power, are only powered on momentarily when needed, using clever MOSFET switching. This meticulous power management allows a single sensor node to achieve(theoretically) weeks of continuous runtime on just 4 standard AA batteries. This means less frequent battery changes, minimal disruption to your monitoring, and true independence from external power lines. And this is before putting everything onto a single PCB and simplifying and optimizing everything.

What about the code?

Beyond the hardware, the software driving this project is built for reliability and future growth. Instead of a simpler framework, I've utilized the ESP-IDF frameowrk, which provides a more robust and professional development environment for the ESP32.

Furthermore, the system relies on a proper and future-proof communication protocol with a robust packet format. This ensures that data transmission is efficient, reliable, and that the system can easily adapt to new sensor types or features in the future, providing a solid foundation for continuous innovation.

If you're interested, you can check out the project here!

Thanks for reading :)

So I tried to deobfuscate the JS, which resulted in this.

Moving on, the 404 page has this eerie looking image, I'm currently trying to parse through it for any hidden messages. performing strings on the image reveals the following

$ strings areyoulost.png
IHDR
        pHYs
iTXtXML:com.adobe.xmp
<?xpacket begin="
" id="W5M0MpCehiHzreSzNTczkc9d"?> <x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.6-c145 79.163499, 2018/08/13-16:40:22        "> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description rdf:about="" xmlns:xmp="http://ns.adobe.com/xap/1.0/" xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/" xmlns:stEvt="http://ns.adobe.com/xap/1.0/sType/ResourceEvent#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/" xmp:CreatorTool="Adobe Photoshop CC 2019 (Windows)" xmp:CreateDate="2024-11-05T21:11:30-06:00" xmp:MetadataDate="2024-11-05T21:11:30-06:00" xmp:ModifyDate="2024-11-05T21:11:30-06:00" xmpMM:InstanceID="xmp.iid:761d1d64-ba57-b242-abf2-8bba113e3b47" xmpMM:DocumentID="adobe:docid:photoshop:f256ba5b-60f6-2e44-b517-4fdab717818b" xmpMM:OriginalDocumentID="xmp.did:87957d27-41a5-1344-a13e-b1da34594c7e" dc:format="image/png" photoshop:ColorMode="3"> <xmpMM:History> <rdf:Seq> <rdf:li stEvt:action="created" stEvt:instanceID="xmp.iid:87957d27-41a5-1344-a13e-b1da34594c7e" stEvt:when="2024-11-05T21:11:30-06:00" stEvt:softwareAgent="Adobe Photoshop CC 2019 (Windows)"/> <rdf:li stEvt:action="saved" stEvt:instanceID="xmp.iid:761d1d64-ba57-b242-abf2-8bba113e3b47" stEvt:when="2024-11-05T21:11:30-06:00" stEvt:softwareAgent="Adobe Photoshop CC 2019 (Windows)" stEvt:changed="/"/> </rdf:Seq> </xmpMM:History> </rdf:Description> </rdf:RDF> </x:xmpmeta> <?xpacket end="r"?>
qIDATx
=vQX
\U55
uj[^
4aq{
x1E"
nyHEE
44k?
2U[|
!\8KL
_x[6
c*DX
eYHuT
7ZhP
NQ!#
4WmK"
Vja%
t2P&7j
4t"
"*/"
C>&[
g2g;
yTs[
Tr>p
JxL'Q)
UgEQ
2>VH/
(j'?
x<vJ
/lPiV
J#Do
]~[!
P0Ix(
ER*$
i4iM
j/CJ
1o*q
[t\j
*POF
+M?n
@fe[
vBTq *
_'@oy
tj'L
<mL7k4
aWdf
!odzo-
M(A8
UAV#
P0KT
Z7'B
@:&i
?Q /,
<mK8j
\8]*
VN]_
x'i=.
APJ6
d\z<:F
-  w
?g,~
f47U
J+2<
V24EU
=r8b
Q@g4
@>X<
XNT-
':BqJ
_ddl7=yJ
        2:3
q,('
r1K.m
p8tneS
Q{)Q
w*SZ
,!j_
d&<n
V`,p
$j|d>
y`$g
f;g/7i
<-j^U
"Bc2
meej
?T|%6P
J%P;k
nAP3
Xmwe
 cQk
[B4Y
9Q      5
OW{uF>q
B`xny
@v,"?
3SniS
A]g*
>[ZQ
j8.m?
-[<-
 x~J
vzs=K
%BTD8*
J[&x*
--D2
s7tHG
*ZXX
t:t<
?:::::zo
sssJ
8::RJ
,..ba4
X5_2N   Xo
Zk>O[
D9Px
PMm7
B$<`
dxls!
|J)'
HD5??
Rj~~~aa
mi\E8
fYF/
TJ-,,DQ
xpp`
XMkM\
b=Soz\X2
l#`<
ppP/@
E+A;:HQ@
/u:'
h.28
?<<<<<
{eAp
$I(/
XZZB
P'Fh/
-.F8l
>L5     C
{{{!=`
Iw~~~ii
%pV#k
4MIU
MrF^
WVVh
_ZZBSlqq
KKKh
y'++
mWU`Q
Rjnnn
CsssGGG
eP,-
kDN+
$s"):
g&y}CZ2
G;2d
ssst<
`0hN
Rjkk
/^4gz
*       9::
4JSHS
eoOF
(T9 W
9BG*o
(see
Rj{{
l>(p~
O777
pa}}
3gVWWI
,-----
?WVV
t|ppPT
6onn
% w{
K%ix2
J)45
9r}}
iiiaa
x|-M
vH{Q
WJ-,,
ggguuu
qm@#
gV*ppp
 fB.
jhc`
+k,0??Oj
ytp?
5c;N
(X6"qa
|ycc
GGG~J
&]^^FO)JV
ZG95N
4`cT)uxxXd
+nC>0
kOI(
_Q      ?
mY@q?
U']*eA*
(A)utt
[[[h
wvv^
VVVn
sii
ein&
kT1OL%
`0pR
&F!jU
'ZkJ
B5i\bJ-
|<~     p
s!~nm!
-riL;
!|Dh
>j+M
4Q z
|gdmc
oX[[
'B;@(
}wwwz
9-%IB
AoN"D=
766666._
j"`gk[
ppppp
!H2*7
2BG*
Rjiiiiiiee
u_U\
K|d_
HgrI
huuuiiiqqqii
teK3H'0
 pF9
g:8s
3gvwwwww_
'2"/i
+ljg
zc)D
K$(3
kkkJ
j{{[
hT4<
nW)E
/5O)u
FkMV
Zoll
*(*Co
\]]UJ
"hGBnI
sssGGG
+}H|m
+W.]
xxxH
!Cd>
W_}E
faaAk
&VR7
(`:6
B'wvv0_
9o$fO
2Hi]I[t
vvv^
O777
$       vB
}JK[
c;2L
7Q`#
RKKKD
<8::B
(py>
9       Z1
 jjcoF
C'677777
`L]r
.mll`
'0{.
cx!!
g@+(
2=q>;
yy=q
]**fd
;`I5
j0(-
d)\(
E((G
@pZ!
=~oA
VbA
~ciIw.O
:i5I
@G*2,9
F#ja
Km}}
>@.G
E(y0
z=<O
sssZ
6       Ei
{766
q677
O+++
B@!v
LqvQ
1b;*c
pd,B
e{{{
{{{!r
P#bR4
\TfgggwwW)
%766
;;;;
zii)D
'pz&IB
v;sss
ZXXX\\
[ZZZXX
3??OJ
Z]]E7
*R)e
5D*B
4MSg
'ar}
3kkkJ
U*c7
f`xLqC=9?
sD\Y
&WWQ
W766
K777+e
Nm\k
wvvVWW
*~Mfgg
5dDc
JUpc
y27/I[
gEN3
888@9
k3Ui
Niy#e
hz@6
J)NY|
N+PO
        Z7      N&
Ij4d
g#0LH
u{nn
DQttt
}\^^
laaq~~
%eF 8M
SXk}ec
OQ,Z
n@1BN
*I&#
|kTP
Y]xz
y.!/
".|w
nW3
G"9N
3@Nx
vww_
gWWW
wwwwww_
+++KKK
Vr>p
KKKQ
*R M
$IP,
++++++
?[D
&0/c
766666P
=zdXH
[ux@l7
mS~)R
flnn
?88x
*A$H
;R^6
J5^6
isss
xsKKK
KKKx
Rjgg
^UJmll
zGWWW
,;::
ODH'
[x-5
.=41
`0@^
U<^\\\
7cG+
['Apw
mi^2
ZgYv
b<2K
GGGGGGF
mooommmmm9
EDcx
2epx|
%ijh
=8yK
:1B:
#D}D
Y[[[__
o?"C
+++|
U+J+
I7E[
^ui+
czS!
.r&'
i=qxxH
`kkkss
16F~
de{ZNc
pkhB
|#*L
?+cK
A,BA}
O x_!D(
S ]E
,H%a
qCk}
JBvvv
xaaa~~~aa
ag_"
eB>Q
`aaaqqqiiIM
|Y3
^onn
F!_}
C,Q,6
T>MS
{{{h&
3(s{{
]akk
K^Vg
lll`y
\___]]
b;;;
t<77
vvvp
r$yh
WO5^6
?<<TJ
[^^^ZZZ^^
Z///Sg
Zooo
,.."
Hsj.
xa||r
=::ZXX
/+ja
F4sx
$!Vv
FI:v
F{h5
TX[[[
=;zdh
.\X__
Y3kkk0Ix
UxRk=
dV<5
;g<3
rgiQ
I'<_
&!_Rt
M~Fy
~}xx
 bss
>zcs
^-'S
wjSv(w
c~</f4
=::Bo|
PyC{x
^GOZ
nooooo
':BqG
?~\Z
<:::<<
\CQdnR
p8TJ
tE\h
M       'J%
0G.n
e"d0
ammmuuuee
Kwww
pB]M
L_A)
"!J)
S       !BAk
P xG!D(
sJHrt:
Po4'B'
t:t<
$Q /|
IbA^X
h4jE
(P)E%a
ccxa
Jsz~ZY
eeeeyy
sssGGGx
?Q`%
r3:D
;tqqqnn
Tn~!$
?X~D
_>pc.
i-y~
<880
X#@`k
41yt0b
(SIfi
`xGI
?::"
CmaynK54_
(2#J
Od;Tm
E1B{+
]LqqG
v8*5
`2z7
%g#n
_~J
;\XX
09`x^
gP0P
uSQZ)
_Tk=77
UC0\
zF~e
,Cz~
S /,t
:,ER^
ayl!
 uN[]Q
<Z/R
F<hb
<i[\
Xf6g{@#<
2xLWm=
&E~jz
u:Nq
s*7?P
bGGG5
t;j3'c
O&IR
&I277g
sP[I
C`6)
rM^I
dQbA~
1^~>
B~mJS
0! s
E^;G
SU`)
(VWU
Z4Rm?
sN@:
Eyris
8e[&o
}qtz~
JC]v
        #cp
h;cVP
Mm`_
#       _g
qI?DQ
rriW2G
T"9.
)R<O
ieej
DmhE
A`0.
fXHML
EB**
y|      C
=77g
XQ%P
y.D{vI
TaxG
0<0\
m#Q8
FLS)dH
]M]{
I=9d
+&|>
OKsT
VCZU
s5P8
oQ0|
i6FmM
AT:=
lOy4E
X j_
(""l
iNKNZ
)C%!
~       G5
J)<S
        jM6
\orgQ%p
,9:p
F6<T0I
hyHEE
#tUj
FNE]
34Xj
~H?l
{Ex^
bkw|%>kq
KM7t
y:vN
i(R]
(L:Y
s9PZ^
FKB\
jK*A[
~"TJ
P IC
zG1h
`2:Oo$MS
S5M(:h
&=HE
qjeej
[Akm
efYVd
.PoqD
Qyh
eZ$y
-i      "Q
p_G=x
UtWf
B(!c{
-:ZO2
ceerWB
fpY'
^rlz
'D      WB
W^L=]
%DXd
$$~r
kBV4
9U@fEA
B$SX1d
G]Ua
        ;@%
t iE
 N:i
VX(<
"       zF
#Tm'X,
L[AGC
?XJVYN
m+ja)
PfCBu
0,Q=
oX6v3
dt~0
M-]l
5WyN4i
%Gm
yH%c#
ni*Uk
%3ki
)Mr}
*.gun"
        }a0z
f{__}
dwv!.XL;
@58|
r8[0
?xMH
O}\2
IEND

CHECK YOUR client_max_body_size! I changed it to 25GB

god I don't want to admit how long this took for me to figure out...

Thanks for reading :)

I will be publishing a whole long post on how I wrote it... maybe

Well I never really understood how someone would program in a language that could never be run so... here I am to fix it

How is this called pseudocode when it is so well defined here that I can write a compiler for it? I have no goddamn idea but its fine

I mostly plan on hosting this as an online service so my CS teacher can use it in her classes but also doing this for fun so

You can find the source code and progress on GitHub (pls star)

I know I barely post anythere here but,

Thanks for reading :)

And then I realised it's too much work and switched to Ghost... so here we are

I've had some more thought on what I'll do here and mostly it'll be project devlogs, along with solutions to programming issues I encounter, and also the occasional rants.

Oh yeah, things are probably broken too, just send me a mail at me@satyamedh.me or satyamedh9@gmail.com .

I've got a few things in the queue, by the time y'all are seeing this(I mean, who'd be seeing it anyway) I might have a few other posts out.

Oh yeah, I would like to thank ChatGPT for the name of the blog too

Thanks for reading :)