devnoname120

#!/usr/bin/env python3

import sys
from xml.dom import minidom
from functools import partial
import grequests
import hashlib
import hmac

devnoname120

.psv Structure viewer

This little specification allows to view the structure of .psv files in 010 Editor.

This allows you to get a quick overview of the keys, the signature, and the sha256 hash.

In order to use this specification you need to:

devnoname120

/**
 * Motivation: One unified .psv format for archiving (preserving) Vita games.
 * The goal is to preserve as much of the original game structure while ensuring
 * the all the information needed to decrypt and extract data can be derived
 * from just the file and a hacked Vita.
 *
 * We want something akin to .nds or .3ds/.cia or .iso but for Vita games. The
 * unique challenge is that Vita cart games require a per-cart key to decrypt
 * and digital games require a similar key from activation. With just the raw
 * game image, it is not possible to extract the game data.

devnoname120

#include <stdio.h>
#include <arpa/inet.h>

int main()
{
  struct sockaddr_in sa;
  char str[INET_ADDRSTRLEN];

  inet_pton(AF_INET, "192.168.0.1", &(sa.sin_addr));
  printf("0x%x\n", sa.sin_addr.s_addr);

devnoname120

#define DEVICE_BASE         (0xE0000000)
#define IFTU0_BASE (DEVICE_BASE + 0x5020000)

uint *iftu0_base = NULL;

static inline void turnon_oled(int a2, int a3)
{
    if (a2 == 128)
    {
        *(iftu0_base + 0x2000 + 32) = 0;

devnoname120

DB Lookup

Overview

This file is a reference database of every exported functions on a PS Vita running firmware retail 3.60.

Why?

This is helpful to create db.yml tools. For example, I can make sure that every NID of the vitasdk actually exists. I can also use this to find the library and module corresponding to functions in a NID list.

devnoname120

0x80010016 = subdirectory limit reached
0x80101104 = trying to install a VPK that has a corrupted entry in the vita db (edit ur0:/shell/db/app.db to get rid of it (you can use https://anthe.studio/bubblestudio/), and delete the ux0:/app/thebrokenapp folder)
0x8010111C = head.bin missing from package being promoted
0x8010113D = trying to install a package that has livearea images that were not run through pngquant
C0-11278-9 = cannot delete bubble (why?)
C1-6775-5 = launching unsigned app from official firmware
C2-12828-1 = Uncaught exception (abort() called). Happens in normal use when the memory card has corrupted sectors.

devnoname120

<yifanlu[m]> okay I'll engage in this one last time
<yifanlu[m]> evolution of build systems (for C)
<yifanlu[m]> shell scripts => makefiles => automake => autoconf/cmake
<yifanlu[m]> saying makefiles are better is like saying the model t is better because it gets you from point a to point b with no issues
<yifanlu[m]> while missing all the advances people made for a couple of decades
<yifanlu[m]> "but my ford fiesta is so complicated. I don't understand how it works!"
<yifanlu[m]> I agree autoconf/cmake are not perfect systems. and they are more painful to write/maintain.
<yifanlu[m]> but the idea is at some point you will run into a wall
<yifanlu[m]> "oh shit how do I do this"
<yifanlu[m]> and you have to hack together a solution

devnoname120

for f in $(find . -name "*.c"); do mv -- "$f" "${f%.c}.cpp"; done

devnoname120

jsonschema -i dbv2.json db_schema.json > db.log 2>&1
0x8: '0x8' does not match '^0x[0-9A-F]{8}$'
0xCE: '0xCE' does not match '^0x[0-9A-F]{8}$'
0xCF: '0xCF' does not match '^0x[0-9A-F]{8}$'
0x0: '0x0' does not match '^0x[0-9A-F]{8}$'
0x71: '0x71' does not match '^0x[0-9A-F]{8}$'
0x3A: '0x3A' does not match '^0x[0-9A-F]{8}$'
0x38: '0x38' does not match '^0x[0-9A-F]{8}$'
0x3: '0x3' does not match '^0x[0-9A-F]{8}$'
0x5: '0x5' does not match '^0x[0-9A-F]{8}$'