# JTAG 6: Additional Topics - patching getty

**URL:** <https://discourse.securinghardware.com/t/jtag-6-additional-topics-patching-getty/73>\
**Category:** APA #1: Embedded & IoT Systems\
**Created:** [May 9, 2022, 6:22pm UTC](https://discourse.securinghardware.com/t/jtag-6-additional-topics-patching-getty/73 "2022-05-09T18:22:41Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![m0rv4i](https://discourse.securinghardware.com/letter_avatar_proxy/v4/letter/m/ce73a5/32.png) [@m0rv4i](https://discourse.securinghardware.com/u/m0rv4i)\
**Post date:** [May 9, 2022, 6:22pm UTC](https://discourse.securinghardware.com/t/jtag-6-additional-topics-patching-getty/73/1 "2022-05-09T18:22:41Z")

</div>

Hey,

Just checking my understanding of what’s going on when we patch the `getty` binary: when the device boots the kernel loads and mounts the filesystems from the flash chip into memory, we’re patching this version of getty on the in-memory filesystem which then in turn will get loaded ‘into-memory’ when it gets mapped as part of being executed when we login.

This is _not_ memory mapped IO talking to the flash chip directly, and will _not_ persist.

Is all that accurate?

Thanks!

---

<div class="post-metadata">

**Author:** ![admin](https://discourse.securinghardware.com/letter_avatar_proxy/v4/letter/a/3ec8ea/32.png) [@admin](https://discourse.securinghardware.com/u/admin)\
**Post date:** [May 9, 2022, 6:43pm UTC](https://discourse.securinghardware.com/t/jtag-6-additional-topics-patching-getty/73/2 "2022-05-09T18:43:07Z")

</div>

Correct - we’re not talking to the MMIO flash storage, and nothing will persist - but - we are modifying the in-memory execution copy, not a ramdisk or filesystem-in-memory copy if there is one.

When the system boots, it spawns a getty process that sits and listens on the console - the program execution has started, code is paged into memory, waiting for a connection that will context switch to that process and start running. We modifiy it then, while it’s sitting there in memory.  
If the getty process restarts, we lose the changes.  
If the getty process is paged out to disk because of low memory- we _may_ lose the changes if there’s already a copy in the pagefile that wasn’t modified.  
If there are multiple instances of getty running on the system - we _may_ have two copies in two different places in memory.

Make sense?

---

<div class="post-metadata">

**Author:** ![m0rv4i](https://discourse.securinghardware.com/letter_avatar_proxy/v4/letter/m/ce73a5/32.png) [@m0rv4i](https://discourse.securinghardware.com/u/m0rv4i)\
**Post date:** [May 9, 2022, 6:48pm UTC](https://discourse.securinghardware.com/t/jtag-6-additional-topics-patching-getty/73/3 "2022-05-09T18:48:29Z")

</div>

It does thanks, so the filesystem is not loaded into memory at all but mounted and accessed via MMIO, and as squashfs is RO we can’t edit the stored version.

I also assume for a lot of IOT devices paging to disk isn’t an issue as it won’t be enabled if there’s only FLASH storage? Using a pagefile sounds like it’d burn out the storage quickly much like the FAT32 example.