hrydgard

// Minimal audio streaming using OpenSL.
//
// Loosely based on the Android NDK sample code.
// Hardcoded to 44.1kHz stereo 16-bit audio, because as far as I'm concerned,
// that's the only format that makes any sense.

#include <assert.h>
#include <string.h>

// for native audio

yuriks

Handle arbiter;

struct Mutex {
  // 1 = unlocked
  // 0 = locked
  // -n = contended
  s32 val = 1;
  
  void acquire() {
    while (__atomic_fetch_sub(&val, 1, __ATOMIC_ACQUIRE) != 1) {

Subv

Kernel synchronization

The AppCore uses a mostly cooperative scheduler, however, it is allowed to preempt threads under some specific circumstances, see the Rescheduling section for the cases where the scheduler may preempt a lower-priority thread to let a higher-priority run.

Each core has its own KScheduler instance.

KObject waitlists

Each KObject manages a list of threads that are waiting on it. This list is iterated over each time the KObject is signalled.

SciresM

Retail NAND FIRM:

Perfect Signature:
B6724531C448657A2A2EE306457E350A10D544B42859B0E5B0BED27534CCCC2A4D47EDEA60A7DD99939950A6357B1E35DFC7FAC773B7E12E7C1481234AF141B31CF08E9F62293AA6BAAE246C15095F8B78402A684D852C680549FA5B3F14D9E838A2FB9C09A15ABB40DCA25E40A3DDC1F58E79CEC901974363A946E99B4346E8A372B6CD55A707E1EAB9BEC0200B5BA0B661236A8708D704517F43C6C38EE9560111E1405E5E8ED356C49C4FF6823D1219AFAEEB3DF3C36B62BBA88FC15BA8648F9333FD9FC092B8146C3D908F73155D48BE89D72612E18E4AA8EB9B7FD2A5F7328C4ECBFB0083833CBD5C983A25CEB8B941CC68EB017CE87F5D793ACA09ACF7

Exponentiated Message:
0002B31331C710412333A587890F9CF0B6A86E71C8A78F96B76082903B3E54EA9AB935978BBF2493BB829E9A5A6060B0C7811881176BCF9FE8B1C5C5E0A95327DB8B52EC178A884AD9CF28DB8BBF2922C05FD034AC81BD231AEB0CBEF6F7DE6F3A30812B9F9A83BF33251891BFA18FA38A64C6FF5F77DBE11C3780C23EA9F6D00F9C01D6FC8A878591D36C4F64ACA6B8D11BBEB21476103C6E86FF2196D465BA4DB78F81F1D3BCCA186BDDD56739A12DD36122F3F5B3DD518DDAC4FA29395EA4CD9DFD80AF8A399990F4FDD3CD6B07EC2122437CCFC3B62B1D1493A7DBB442003

LiquidFenrir

1.	enable debugger in rosalina menu
	go to process list
	select a process

2.	launch arm-none-eabi-gdb <path to elf>
	command "target remote ip:port"
	
3.	command "continue" or "c" to resume execution

4.

dougallj

global _time_load
global _cache_flush
global _run_attempt

extern _bools
extern _values
extern _pointers

section .text

roblabla

Muh Switch Keys

So you want to decrypt switch content ? Well, the good news is that all the tools required to do that are written up! The great news is, since this is crypto we're talking about, you'll have to find the keys. Yourself. Like it's easter.

So here you can find a template of the $HOME/.switch/prod.keys file that hactool uses to decrypt content. It contains all the SHA256 and location of the keys and seeds, so you can find them yourselves.

Note that all the seeds (the keys that end with _source) are used along with the master_key_## to derive an actual key. If you have somehow obtained the key without the seed, you can rename xxx_source to xxx_## (where ## is the master key number) and put your key there.

How the heck do I obtain dem keys ?

wwylele

#include <3ds.h>
#include <citro3d.h>
#include <string.h>
#include "vshader_shbin.h"
#include <stdio.h>

#define CLEAR_COLOR 0xFFB0D8D5

#define DISPLAY_TRANSFER_FLAGS \
	(GX_TRANSFER_FLIP_VERT(0) | GX_TRANSFER_OUT_TILED(0) | GX_TRANSFER_RAW_COPY(0) | \

TuxSH

# Copyright 2017 Reswitched Team
#
# Permission to use, copy, modify, and/or distribute this software for any purpose with or
# without fee is hereby granted, provided that the above copyright notice and this permission
# notice appear in all copies.
#
# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS
# SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
# THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY
# DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF

SciresM

There'll be two stages in the core fusee payload, loading configuration from a shared ini file (https://en.wikipedia.org/wiki/INI_file).

- Stage 1 will be the actual exploit payload, and it will be fairly minimal:
    - It will initialize DRAM, and initialize the display.
    - It will load a filename and address for stage 2, loading stage 2 into DRAM and jumping to it.
    
- Stage 2 will be a "loader" -- it will be responsible for loading everything else into place prior to boot.
    - Stage 2 will be able to load arbitrarily many files to arbitrary load addresses off of the SD card.
        - Stage 2 will get a list of files to load from a "loadlist" key, with loadables delimited by "|" in the value.
        - For each loadable, a _path and _addr key will be used to identify a filename and where to load it to.