]> Chaos Git - corbenik/corbenik.git/commitdiff
Improve some documentation based on in-progress RE, zero-fill new program break ...
authorchaoskagami <chaos.kagami@gmail.com>
Wed, 28 Sep 2016 16:41:29 +0000 (12:41 -0400)
committerchaoskagami <chaos.kagami@gmail.com>
Wed, 28 Sep 2016 16:41:29 +0000 (12:41 -0400)
patch/prot.pco
source/std/allocator.c

index c84e1577145f4e2452705643251fa2d5faa302dc..4a45f40359a4e0b5caedec854d5ccf709b7f6c9a 100644 (file)
@@ -5,7 +5,30 @@
 # $uuid 08
 # $flags require
 
-# Status: Untested, but theoretically fine (Next system update I'll either brick or I won't.)
+# Status: Working
+
+#
+# The firmprot patch works by nop'ing out a call in Process9 which normally
+# is called post-update of the FIRM. Normally it is responsible for writing exe:/<titleid>/.firm
+# to the NAND.
+#
+# We first search for the 'exe:' string because this is a reliable constant located at the end
+# of the stated function and is consistent through firmware versions. The full string is (null-terminated):
+#
+# "exe:/%016llx/.firm"
+#
+# Afterwards, we seek back 0x100 - which is close enough to the beginning of the function.
+# Then we search for the following thumb mode code:
+#
+# cmp r0, #0
+# bge loc_8043f82 ; relative jump
+#
+# This is then replaced with the following assembly to stub out the NAND writing routine
+# and prevent it from ever being called:
+#
+# movs r0, #0
+# nop
+#
 
 rel section2
 # String: 'exe:'
index 4b21ed90196f2e2743bfaeb1abc208c1f8a4f144..6ce278cd26722644700fe593a12ab4587f4a2134 100644 (file)
@@ -8,18 +8,21 @@ static uint32_t *heap_end = NULL;
 extern uint32_t __end__; /* Defined by the linker */
 
 void* sbrk(size_t incr) {
-  uint32_t        *prev_heap_end;
+    uint32_t        *prev_heap_end;
 
-  if (heap_end == NULL) {
-    heap_end = &__end__;
-  }
+    if (heap_end == NULL) {
+        heap_end = &__end__;
+    }
+
+    // FIXME - Make sure heap isn't leaking into stack here. That would be bad.
+
+    prev_heap_end = heap_end;
 
-  // FIXME - Make sure heap isn't leaking into stack here. That would be bad.
+    heap_end += incr;
 
-  prev_heap_end = heap_end;
+    memset(prev_heap_end, 0, heap_end - prev_heap_end); // Clear heap.
 
-  heap_end += incr;
-  return (void*) prev_heap_end;
+    return (void*) prev_heap_end;
 }
 
 // This is an incredibly crappy and inefficient implementation of malloc/free nicked from stackoverflow.