Website: https://gaycat.software
NSFW Account: https://pounced-on.me/@nil
FA (NSFW): https://www.furaffinity.net/user/gaywardcatabond
NixOS: btw

Last Notes

RE: https://mastodon.social/@lina19942810/116235187742524963
This is urgent! Spare the cost of a meal to help save this family!
#note1arv…p6tf

2025-09-17 23:44:10 UTC

https://bsky.app/profile/pseudonymjones.bsky.social/post/3lyxqts7nbc2y
https://furry.engineer/system/media_attachments/files/115/222/290/346/886/508/original/5cb4526c613b12dc.png

2025-01-01 22:51:22 UTC

- reply

so if it makes anyone feel better i just got the actual real code to print out the message. i had to nop out everything before the time validation function so it would run, but indeed this program does check the date and exit if it's too far in the future
https://furry.engineer/system/media_attachments/files/113/755/540/742/008/203/original/a4bab031d64e73bd.png

2025-01-01 22:22:10 UTC

- reply

the majority of this function is just parsing a hardcoded string ("Mar 1 2004") to convert it to year, month, and date integers. this isn't the future limit date, btw. the program also checks if the date is too far in the *past*. looks like the hardcoded last allowed time you can run this program is midnight on December 31, 2009

2025-01-01 21:41:26 UTC

- reply

ok now i'm curious. i'm opening up the program in ghidra, and it turns out there's a check for the future and the past?? and there's debug symbols too, so that's nice... i'll try to clean up the decompilation of validate_system_time and show what it does

2025-01-01 20:48:48 UTC

- reply

i spent hours trying to get this program to run for the bit and then gave up and just faked it with a shell script. why am i like this :)

2025-01-01 20:47:47 UTC

me neither, solaris
https://furry.engineer/system/media_attachments/files/113/755/050/975/963/358/original/515912dae306fd33.png

2024-08-25 01:30:12 UTC

oh my fucking god. so i was having a problem when i enabled optimizations when compiling the doom port. memcpy ended up overwriting itself. so i looked into what was happening, and apparently memcpy just kept calling itself over and over. the reason? i was compiling my own version of memcpy, because i wasn't using the standard library, but i also didn't use the "-ffreestanding" flag, so gcc assumed i *did* have the standard library. so gcc, in its infinite wisdom, saw a memcpy-like pattern in my memcpy and turned it into another call to memcpy, resulting in a stack overflow.
https://furry.engineer/system/media_attachments/files/113/020/067/892/323/529/original/9e6225152056b362.png