lolhax.org http://lolhax.org Development blogging from Davee Sat, 11 May 2013 05:01:51 +0000 en-US hourly 1 http://wordpress.org/?v=3.5.1 Introduction to Return Oriented Programming http://lolhax.org/2013/05/11/introduction-to-return-orientated-programming/ http://lolhax.org/2013/05/11/introduction-to-return-orientated-programming/#comments Sat, 11 May 2013 04:33:46 +0000 Davee http://lolhax.org/?p=158

This will be a small introduction into return oriented programming, commonly referred to as ROP. I’ve had a lot of experience with security measures (duh) but never really had any hands on experience with more modern security technologies such as non-executable stack/data (DEP, NX, XN, W^X) or Address Space Layout Randomisation (ASLR).

The non-executable stack isn’t really limited to just the stack, anything that isn’t code memory can’t be executed. So as in PSP, you can’t just jump to the savedata and have the day’s work done. No, instead the only code executable is real code provided by the OS when binaries are loaded. This is a nice and funky way but ROP is the counter and tends to poop on this method.

Now, ROP is really cool. Rather than execute your code, you control the stack and execute provided code. Sounds pretty weird, right? I mean, how do you control anything if it’s their code? You’re right in a way, their code isn’t our code. However, we don’t necessarily have to execute code in the same way that they do. I mean, they could have super_duper_function located at address 0×80000000, but just because the function is there, doesn’t mean we have to start our execution there. For example, lets consider super_duper_function does the following:

0x80000000: PUSH {R4-R6,LR}
0x80000004: ... perform algorithm
0x80000050: POP {R4-R6, PC}

First it saves registers onto the stack, then does the algorithm, then restores the saved registers and leaves. Pretty standard stuff here, nothing odd. However, if we control the return address, we can’t execute our code BUT if jump to 0×80000050 then what happens is that more data is loaded from the stack (R4-R6) and the new execution position PC is controlled.

Now, this doesn’t do anything in specific but you can see how this works out. Rather than execute functions as you expect, you essentially build a list of code snippets called gadgets and then you chain them up to perform a task. Lets say we want to do a printf. If we control the entire contents of the stack, we can start off by calling the POP-R4-R6-PC gadget. Suddenly, we control R4, R5, R6 and the program counter.

Consider the next gadget:

0x80000100: PUSH {R4,LR}
0x80000104: .. do stuff
0x80000170: MOV R0, R4
0x80000174: MOV R1, R5
0x80000178: BLX R6
0x8000007C: POP {R4,PC}

Now, we don’t want to execute the whole function, but if we execute to 0×80000170 then what we’re essentially doing is the following:

POP {R4-R6}
MOV R0, R4
MOV R1, R5
BLX R6
POP {R4,PC}

See? we’re chaining gadgets and now we have a function control where we can control the first 2 arguements from the stack without even touching our code. So, first gadget; if we go ahead and set R4 to point to our message, R5 to our optional arguement, R6 to the address of printf and PC to 0×80000170 then we’ve chained together a printf that we control completely without a single drop of our own executable code.

There are a few problems with this though… Gadgets aren’t always easy to find. Especially when it involves specific things like the stack. As ROP code is working its magic, the stack is shrinking away at a variable pace (depending on the gadgets). Now, sometimes you need the address of the stack, variables are loaded from there usually, so if you want to save a return type from something like fopen then you need to store it onto stack (this isn’t the only way to recovery return types though). To store something on stack, you need to construct gadgets in a way that it can safely overwrite data in the future (relative to execution of the ROP stack) so that it is loaded when a POP takes place. Yes, it is a little complicated and there are some gadgets that can ease things.

It’s wise to recognise that your development fun is at the hands of the their compiler and code design. The compiler can do some funny things that is useful, e.g:

0x80000120: MOV R5, R0
 
loc_0x80000124:
0x80000124: MOV R0, R5
0x80000128: POP {PC}

This gives a lovely control of R0 into R5, a register that we can more easily manipulate (usually). Sometimes, there is just a pain finding the right things to help you. Times like this, it is better to try and use tools to automate the process, but the more complicated gadgets are difficult to find.

Enough about the gadgets, lets talk about architecture. Architecture lends a hand into ROP, mostly when it comes to CISC and RISC. x86 have an absolute baller of a time due to the fact that args are loaded from registers anyway so you just need to go apeshit and call them. RISC is typically a bit different. By using registers extensively, you add another layer where you need to get the correct stuff into the correct registers in order to do the correct thing. This isn’t exclusive, but I see it as more common. However, other than that, the principle of ROP execution is the same, and can be treated exactly the same way.

ROP sounds pretty cool, right? I mean, it poops on execution protection, whatever can the world do? Easy. One of the most effective ways to combat ROP is to incorporate ASLR. I mentioned this earlier but now I’ll gently explain why ASLR bends ROP over. It moves things. There, ROP is countered. ROP requires everything to be static, notice we need to use exact locations in order to even execute anything? Yeah, move it around and ROP doesn’t work. You could say, “Why can’t we just search for it and then dynamically provide a ROP payload??”. Well, you can but good luck finding something that’ll expose such information, since ROP can’t even start, you can’t use ROP to search. Hence the counter to ASLR is either prediction, controlling and/or identifying the locations of memory. If ASLR is used without execution protections, then you can attempt a heap spray to try and get control of data at a significant array of addresses.

So, data execution prevention and ASLR is probably the strongest way to protect a system, but mostly the effectiveness is based upon ASLR. As soon as addresses can be predicted, then huzzah, ROP.

This’ll do for now, If I’ve been a little vague let me know and I can update/repost with better clarification. Since I’m naturally a tease too, I’ll be showing off a cool little project related to this kind of stuff (it isn’t anything amazing, but just a bit of fun!).

]]> http://lolhax.org/2013/05/11/introduction-to-return-orientated-programming/feed/ 2 PSVita Native Hack, c’mon devs! http://lolhax.org/2012/09/02/psvita-native-hack-cmon-devs/ http://lolhax.org/2012/09/02/psvita-native-hack-cmon-devs/#comments Sun, 02 Sep 2012 14:23:32 +0000 Davee http://lolhax.org/?p=152

Just to start, congratulation to yifanlu for his excellent work on gaining the first vita native hack. I’d like to note that I’m just relaying information from a forum post by yifanlu and did not have any input on yifanlu’s work, it’s all his!

Also, if you’re not a developer, please note that there is currently no way to run homebrew, colour your screen, download binaries, hack your device, make a milkshake from 10 miles away or such. This post is purely informational.

Continuing on, considering my audience gathers quite a few developers I think this post should complement the cause. So, if you don’t know, vita dev yifanlu has been looking around for developers who are interested in developing native software on the vita. He is calling out for developers to help him develop an ELF loader.

To quote his post:

As of right now, I have not tried compiling the code yet. It’s mostly just pieces of code for things like the ELF parsher, resolving NIDs using module exports and syscalls from both imports and exports and etc. I am basically looking for people with experience in HBL to help me finish this. Currently, I am missing code to clean the memory (releasing heap pointers, unloading all modules, deleting threads, etc). But mostly, I want critiques on the current code and how things could be improved or if any of my assumptions in the code could prove false. I have tried to make the loader very portable (for other future exploits) by having lots of error checks and only using functions imported from sceLibKernel (which should be loaded by every game). If you want to help, just fork the code and send me a pull request when you’re done.

If you’re interested in getting involved in the first community project for the vita, check out the coding standard for the project grab a copy of the source at his github repo and read the documentation.

As a personal tip, you can get into contact with yifanlu either by PM on the wololo forums or on IRC (if you prefer more IM like banter) at irc.efnet.net on channel #vitadev.

Happy coding!

Source: wololo forums post by yifanlu.

]]> http://lolhax.org/2012/09/02/psvita-native-hack-cmon-devs/feed/ 7 I’m baaaack! http://lolhax.org/2012/08/25/im-baaaack/ http://lolhax.org/2012/08/25/im-baaaack/#comments Sat, 25 Aug 2012 00:06:42 +0000 Davee http://lolhax.org/?p=141

Well, this place has been cleaned up a little bit and I can log back in again. You might of noticed that I’ve changed the theme, and you’ll probably find out that I do this often!

Well this post is going summarise what the hell I’ve been doing since my last post in terms of development and perhaps you’ll be disappointed. Follow the link and find out! Yes, I’m back! If you speak to me on IRC then you’ll quickly find out that I’ve not been away. I have however been busy, which is an entirely different matter. I have been working at a software development company as a summer intern and it has been preventing me working on projects recently. However I’ve been drilling away on a few things.

  1. PSVita.
  2. QtKryptography.
For the vita work. I can’t say much, however there has been some leaps in this area. I’m not here to tease, but if you’re a developer and you’re *serious* about vita development then get in touch with me in comments or the other mirage of places that I exist.

QtKryptography. If you are unfamiliar to Qt, then look it up! Qt is a C++ toolkit/framework that provides a huge selection of tools and functionality that significantly lower application building time. What makes this even cooler is that Qt code runs on a huge array of devices including: windows, mac and linux. This project is here to introduce a powerful way to use cryptography using the Qt library types. If you want to contribute or follow the project, then please follow my bitbucket account.

Other than that, I’ve not really had much time for development. However, my summer placement sadly comes to an end soon and once that is gone they’ll be more time for development (and looking for another placement for next year).

So keep an eye on this page for any useful information. I hope to provide some more information on kermit and provide more updates with my recent experience with C++11.

As always, follow me on twitter: DaveeFTW.

]]> http://lolhax.org/2012/08/25/im-baaaack/feed/ 4 Kermit http://lolhax.org/2012/03/29/kermit/ http://lolhax.org/2012/03/29/kermit/#comments Thu, 29 Mar 2012 00:05:10 +0000 Davee http://lolhax.org/?p=137

Turns out he’s not just a green frog! So, I’ve been throwing this word around recently and it’s probably about time I explain. Kermit, either a protocol or perhaps a funny name (see KIRK/SPOCK) is a communication interface for the PSP emu. Specifically it allows the PSP to talk to the host.

Now, I can tell there aren’t as many developers here, so I’ll try to simplify for the curious minds but this stuff is pretty complicated. I’ll only explain the API in detail as the lower level still need a little bit of clearing up, but here goes. 

Ok, Kermit is here so that the emu can communicate to the host to share resources and other vitality. Perhaps the primary reason is that of hardware; the PSP emu is excluded from many hardware devices. So kermit sets in and allows the system to talk to the vita in order to use the hardware. Blabbering aside, this is the hardware that kermit seems to be responsible for:

  • Memory stick
  • Flash filesystem
  • DMA
  • LCD
  • GE
  • IDStorage
  • Audio
  • Camera
  • Power Control
  • USB
  • OSK
  • WLAN
  • RTC
  • … more

Interestingly, the kermit communication isn’t used for headphone remote or controller inputs.

In order to understand how kermit functions, it’s important to explore the usage of the API. Starting with the power house tool:

int sceKermit_driver_4F75AA05(KermitPacket *packet, u32 cmd_mode, u32 cmd, u32 argc, u32 allow_callback, u64 *resp)

This function is the send command function. It accepts a kermit packet initialised to minimum 64 bytes (no args need to be filled) a command mode which describes the set of commands, cmd: the actual command; the number of args following the 16 byte packet header. It also allows you to pass a boolean value to allow callbacks when waiting for completion and a 64 bit response.

What is important to note is that the packet arguements are 64-bit wide (not 32) and little endian encoded. There is a maximum of 13 arguements that can be passed to the host.

Sometimes, it is needed to send more than the 13 arguements worth of data. This is where kermit provides an API for memory. Shown below:

void sceKermitMemory_driver_AAF047AC(KermitPacket *packet, u32 argc, u8 *buffer, u32 buffer_size, u32 io_mode);
void sceKermitMemory_driver_80E1240A(u8 *data, u32 len);
void sceKermitMemory_driver_90B662D0(u8 *data, u32 data_size);

These function provide the fundamentals for data transmission to the host. sceKermitMemory_driver_AAF047AC is the staple command. It accepts a packet BEFORE transmission to host with the amount of args, a pointer to the input/output buffer and an indicator for the mode. This allows kermit to recieve the buffer of data when it processes the command, or have a place to output the data.

sceKermitMemory_driver_80E1240A and sceKermitMemory_driver_90B662D0 are the opposites of each other, providing input and output respectfully. This API is incredibly simple and is used to send multiple buffers to kermit prior and following a command.

These are pretty crap descriptions, but as you can see it’s a very command and transfer sort of interface. You tell it you have data you want to give it, you signal it and then it tells you where it’s put it.

https://github.com/DaveeFTW/vita_kermit

There is some source code describing in more codey ways. Also there are small reverses of functions used in the kermit. As you can see it works on a sort of circular queue of semaphores in the core. Have a “peek”.

Thanks to Proxima + some1

]]> http://lolhax.org/2012/03/29/kermit/feed/ 19 PS Vita PSP HEN http://lolhax.org/2012/03/21/ps-vita-psp-hen/ http://lolhax.org/2012/03/21/ps-vita-psp-hen/#comments Wed, 21 Mar 2012 16:16:03 +0000 Davee http://lolhax.org/?p=133

First thing first, huge thanks to Proxima and some1. They’ve provided key utilities and advice for this research. So, yeah, it was really only a matter of time till this kind of thing happened. Sony dont just emulate the userland process of a PSP game, they emulate the entire kernel albeit, a modified kernel. The PSP emu has limited access to hardware, with interfacing the hardware done via a Kermit module. Kermit is a old-timers transmission protocol, likely used to talk to the native Vita.

The PS Vita, is a nifty little device, and the PSP emulator is a good target to get a huge library of homebrew. Check out the video below for a demonstration of what can be achieved.

You can see, that it works! The benefit is that HEN can access the core of the kernel, allowing almost seamless compatibility. However, as you may know, VHBL cannot run Lamecraft. Nor can this HEN currently. Lamecraft uses the OSK interface which has been replaced with Vita’s OSK. It’s likely a software error in the PSP kernel from the arguements passed in the homebrew.

There is other things, and perhaps i’ll make a post for them another time, but for now, later.

-Davee

]]> http://lolhax.org/2012/03/21/ps-vita-psp-hen/feed/ 61 Can you crack it? + Solution http://lolhax.org/2011/12/03/can-you-crack-it/ http://lolhax.org/2011/12/03/can-you-crack-it/#comments Sat, 03 Dec 2011 05:30:42 +0000 Davee http://lolhax.org/?p=114

Thanks to a facebook message from my dad yesterday, I was informed of this website: Can you Crack it?. So, promptly, I got onto the job and it was surprisingly easy and I imagine it will be for most people who can reverse engineer and has experience doing so.

Click read more to see how I did it, but I suggest you have a good attempt beforehand. It’s a nice little reverse engineering exercise.

SPOILER – THIS IS THE SOLUTION. RUN AWAY AND HIDE IF YOU WANT TO HAVE A GO YOURSELF.

Stage 1 – Reverse engineering and decryption
Ok, so from the main page, I wrote out all the hexadecimal into a binary file. Like this:

EB04AFC2BFA381EC0001000031C9880C0CFEC175F931C0BAEFBEADDE02040C00D0C1CA088A1C0C8A3C04881C04883C0CFEC175E8E95C00000089E381C3040000005C583D414141417543583D42424242753B5A89D189E689DF29CFF3A489DE89D189DF29CF31C031DB31D2FEC0021C068A14068A341E88340688141E00F230F68A1C168A1730DA8817474975DE31DB89D8FEC0CD809090E89DFFFFFF41414141

I sat around for a good few minutes just reading the hex. However, I noticed something! “EFBEADDE”. This is the little endian storage of “0xDEADBEEF”. Tada, it’s probably code. So shoving it into a disassembler, I get some nasty x86 code. After whimpering at the sight of it, I cracked on and reversed engineered the code into lovely C.

But there was something missing! In the x86, it does a near call which pushes the return address onto the stack. This sneaky little program then pops this off the stack and then sets it as the new top of stack. After the return address, a sneaky pop loads 0×41414141, the last 32 bit value in the file, and then checks it does equal that. Then, it does another pop… wait a second. There is no more defined data, and it is looking for a 0×42424242. So, realising I copied the HEX wrong, I set about correcting it. Except, I didn’t copy it wrong, the data was truely missing! I checked the site source for any html comments; nothing. After downloading the png image on the website (the image with the hex data), I open it up in a hex editor, and I recognise a base64 encoded message in the comments section which indeed turns out to be the missing data!

So further analysis proved that I have all the data required to decrypt and complete this puzzle. I wrote this program to do it:
Show ▼

 

It successfully decrypted the message and decrypt.bin contained: “GET /15b436de1f9107f3778aad525e5d0b20.js HTTP/1.1.”. Ok, maybe I’m not done, following this GET request I got to “stage 2″. A VM in javascript.

Stage 2 – Javascript VM
This, is kind of like an emulator, you get a description of a “processor” and you follow the specification. If you do it correctly, you get the answer, easy.

I started off simply decoding the instructions and writing them to a file, like a disassembly. Then once I was happy that it was decoding it correctly, I scrapped together a simple tool interpret the instructions and then dump everything. Code below:
Show ▼

 

Then, the output_hex.bin contained another GET method: “GET /da75370fe15c4148bd4ceec861fbdaa5.exe HTTP/1.0″. Ok, cool.

Stage 3 – License check
After downloading and having a quick peek at the assembly, I saw it didn’t do that much. After running, it moaned about no hostname, so naturally, I set it to “canyoucrackit.co.uk” BAM, it screamed at me again, complaining about a license.txt.

I fully disassembled the executable and I quickly found the check, it was doing a scanf of a string from the license onto the stack and performing a check of the first 4 hex bytes.

This check looked for the values 67 63 68 71 in LE. This, translates to gchq, a UK government organisation. Regardless, I stormed through the rest of the code and saw that it does a “crypt” call on the license + 4, with a salt (or key or w/e).

char *c = crypt(license+4, "hqDTK7b8K2rvw");
 
if (strcmp(c, "hqDTK7b8K2rvw") == 0)
{
	valid_license = 1;
}

Now, I know for a fact that crypt is a one-way function, so I didn’t bother with figuring out the original license text needed. If you guys know me, I like exploits. I saw one earlier on aswell. I jumped right back to the “scanf” call onto the stack and checked if I can cause a buffer overflow. It turned out I could! valid_license was stored further on the stack, so overflowing with a big string can set valid_license to non-zero passing that check! huzzah!

I used this license:

gchq------------lolhax.org------Davee-----------

So now, running the application I got this result:

keygen.exe
 
loading stage1 license key(s)...
loading stage2 license key(s)...
 
request:
 
GET /hqDTK7b8K2rvw/2d2d2d2d/686c6f6c/6f2e7861/key.txt HTTP/1.0
 
response:
 
HTTP/1.1 404 Not Found
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Sat, 02 Dec 2011 23:44:59 GMT
Connection: close
Content-Length: 315
 
Not Found
HTTP Error 404. The requested resource is not found.

Error, 404, odd. It tried to request “GET /hqDTK7b8K2rvw/2d2d2d2d/686c6f6c/6f2e7861/key.txt HTTP/1.0″. I recognise those HEX values. The first one looked the the hash check, the 2d2d2d2d, 686c6f6c and 6f2e7861 looked like data out of my license file. After confirming with the assembly, this information was true. the format of the license was:

[4 bytes header]
[8 bytes password]
[4 bytes first hex]
[4 bytes second hex]
[4 bytes third hex]
[0x18 bytes to bypass check]

Now, what the hell were these 4 bytes? They weren’t inside the application. I sat around, stressing over what these numbers are. I guessed a few of course, no luck. After a nice chill and a cup of tea, it struck me. There was a spare value in the first executable, which the program just jumped over. There was also the VM’s firmware version which was not used. These 3 unreferenced values may be the answer!

So I plugged them in, and what do you know! I don’t get the answer. Such a perfect scenario, but I still fall victim to this challenge.

Later on though, I thought I should try plug it into the browser… well, what do you know. It worked.
Show ▼

Completed
The winners’ page takes you to an application form to apply for a position within GCHQ. Shame I don’t have a degree yet :P

How about that eh? It’s a nice little challenge and I hoped you all attempted it your best before reading this!

- Davee

PS, due a grammar/spell check tomorrow.

]]> http://lolhax.org/2011/12/03/can-you-crack-it/feed/ 44 “Chronoswitch” Downgrader 5.0. Advanced 09g Support! http://lolhax.org/2011/09/01/chronoswitch-downgrader-5-0-advanced-09g-support/ http://lolhax.org/2011/09/01/chronoswitch-downgrader-5-0-advanced-09g-support/#comments Thu, 01 Sep 2011 04:39:35 +0000 Davee http://lolhax.org/?p=99

As an ongoing project, me and some1 have been enhancing this downgrader from birth on the 6.31/6.35 firmwares. This multi-firmware downgrader allows you to install a lower (or higher) firmware without any fuss. No complex flash0 sharing, just running the firmware update.
However, there comes restriction with PSP models and compatible firmware. For example, a PSPgo cannot run 1.50 as there are no drivers for the system and the IPL format is incompatible. Much like this, the PSP 3000 09g is unable to install firmwares < 6.30 which removes it’s ability to appreciate the flexibility of permanent custom firmware.

This is no longer the case.

It started off with rumours of 09g systems being “converted” to 04g systems with some sort of Sony equipment. I explored the firmware comparing 04g and 09g and there is little difference between the modules, so I looked into what makes a 04g and 09g different. I got various testers (named below) to give me information on their IDStorage and internal system data (baryon/tachyon). From this I can conclude that the only (effective) difference between a 04g and 09g is:

  • Idstorage Certificates
  • Baryon Version

Nothing more.

Now, it was time to see what it did with these values. I looked up the Idstorage certificates, it’s used in Chkreg and used internally to generate a model number. I found out that 6.20 and 6.39 sets the model of 09g to 04g, lovely.

The big game was the value that is returned from sceKernelGetModel(). Where is this taken from? Well, rooting back from the IPL, there is some code used to determine the model. This code used some strange code which turned out to be syscon code to obtain the Baryon version! The model number is determined from the Baryon.

Here is a little explanation of the Baryon version. When shifted 16 bits to the left, the least significant byte is the data used to determine a model number. the most significant nybble contains the SKU (PHAT, SLIM/3000, GO) and the lower specifies the model of that SKU. However, it got me thinking… Sony don’t know how many revision they will produce in the future. Checking 6.39 firmware, Sony does this: [0x2C -> 0x2E] = 04g, [0x2E -> 0x30] = 09g. Rightfully so, the Baryon version from the 04g’s I had was 0x2C and the 09g had 0x2E. Then i though, if they didn’t know the future, then what does 6.20 IPL do? After analysing I found this: [0x2C -> 0x30] = 04g.

So, if for some reason you find your 09g on 6.20, the IPL is gonna think it is a 04g. Ok, we can work with that, Chkreg sets the certificate based model to 04g and the IPL sets Baryon based model to 04g. Now, lets get some 04g firmware in there!

After a bit of thought, I was sitting at the Downgrader source thinking “how can I install 6.20 on a 09g”. Obviously, run the update and spoof the model. However, changing sceKernelGetModel() did nothing. The model must be determined by some other way. So, 123 and I find Baryon code, yay. Once again, the 6.20 updater has the 09g Baryon as a 04g so if it could run on it’s own, it will flash 04g modules. But why did it error?

IDXFFFFFFFF. That’s the error, it’s to do with error opening INDEX.dat. Wait, a second, why is this happening? Oh wait, it thinks it’s a 04g, so it’s looking for index_04g.dat, doh!

Now, we got a new error. This is weird, it originates from a module called “sceChkuppkg”. Heh, cool. After a brief look at the internals a wild idstorage certificate check appeared. It checked a PSAR block against a list of data composing a PSCode. Easy fix, now the 6.20 could run. Once it had run, it rebooted.

Then it bricked.
Yes i fucked up. By only hooking the usermode version of “sceChkuppkg” caused the updater to validate the blocks until it started to do something important… like read the rest of the firmware after wiping flash clean. Everybody, thank “Gamefreeak100″ for the first brave and bold steps into a 09g permanent patch world, he sacrificed his PSP for it.

A lot of reading later, I identified the problem, fixed it and handed it to another brave tester. This time, it worked! 09g was running firmware 6.20 and for the last 12-ish hours it has been running fine. It retains the ability to update to >= 6.30 and seems very stable!

A word of advice though, this is still experimental. The idstorage certificates do NOT belong to a 04g PSP and upgrading and downgrading from

This would not be possible without the combined efforts of:

  • some1
  • Gamefreeak100
  • Chris10Lyn
  • snailface
  • XxGodOfWar2xX
  • mint
  • ponso21
  • Ryone
  • ROE-UR-BOAT
  • diggory
  • Yoti

Give them all thanks! Leave a comment if you think you should be here!

Download

]]> http://lolhax.org/2011/09/01/chronoswitch-downgrader-5-0-advanced-09g-support/feed/ 499 Emma is not well :( http://lolhax.org/2011/07/15/emma-is-not-well/ http://lolhax.org/2011/07/15/emma-is-not-well/#comments Fri, 15 Jul 2011 21:28:15 +0000 Davee http://lolhax.org/?p=97

It sucks, my beautiful girlfriend’s fallen pretty ill and I want her to get real better soon. If you could spare some time I’d appreciate if you’d drop a comment. Hopefully she’ll be up and running soon again!

She’s suffering from some migraines and it’s causing her a lot of pain. Leave something to help cheer her up, it’ll mean a lot to me!

Love you Emma :D <3
Cheers guys.

]]> http://lolhax.org/2011/07/15/emma-is-not-well/feed/ 56 Arduino projects. http://lolhax.org/2011/07/15/arduino-projects/ http://lolhax.org/2011/07/15/arduino-projects/#comments Fri, 15 Jul 2011 21:20:56 +0000 Davee http://lolhax.org/?p=93

Well, I’m no beginner to electronics, but this is my first microcontroller that can directly interface them! So yeah, pretty cool, never messed with AVR in my life, always used PIC for my USB controller. So I’ve been messing around a bit and I’ve done some very basic stuff working with components here and there.

Read on to see the stuff I’ve done.

First thing first was a test to get me warmed up to the equipment. I had a 7-segment display lying around and a 7-seg decoder to accompany it costing me only 4 digital pins. It also made the code a helluva lot easier, basically just reflecting the integer’s lower 4 bits to the decoder. So this was my first project.

Second was the addition of a PS1 controller to control the pulses. Like I said, i’ve had experience in electronics before so really it didn’t take look after reading a brutally-sound documentation on the controller’s protocol. I wrote a small library to interface the controller and then used that to control the 7 segment display. Pretty simple controller interface after that, X increments, O decrements and start resets the counting.

Third was a simple task using the Arduino tone library. I salvaged a speaker out of some old spy toy. Then I looked up the sheet music for the tetris theme and huzza, mix that both together and you get a lovely tune, albeit with minor mistakes within.

Forth and the latest on youtube at least is the PS1 controller synth. Not so much a synth really, but you can see the name potential, yeah? Still using the monotone Arduino tone library (not any PWM based oscillator or external oscillators yet) I added the ability to use the PS1 controller to choose the note to play. IIRC X = C, O = D, [] = E, /\ = F, UP = G, RIGHT = A and DOWN = B.

Then there was the ability to change the semi-tone. L1 changes the pitch down a semitone and R1 up a semitone. This allows the full chromatic scale to be used :D

Then you see the 7-segement display, right? That’s the current octave it is on. It should start on like 5 whichever has middle C and then you can change it to have lower octaves or higher (the lower octaves are sweet).

Press L3 and then use the right analogue stick to control the pitch according to the Y-axis. Pretty cool eh?

Follow me on twitter: @DaveeFTW
If you like what I do and you wanna buy me a beer (I am old enough now ;) ), Donate! ->
-Davee

]]> http://lolhax.org/2011/07/15/arduino-projects/feed/ 11 KIRK 0×10 Private Key http://lolhax.org/2011/07/06/kirk-0x10-private-key/ http://lolhax.org/2011/07/06/kirk-0x10-private-key/#comments Wed, 06 Jul 2011 15:26:42 +0000 Davee http://lolhax.org/?p=81

The private key for the KIRK 0×10 functionality is known to be stored in a encrypted buffer of 0×20 bytes. Proxima discovered that the KIRK 0×10 operates as this:

Kirk 0x10 - ECDSA Sign hash
Invocation:
u8 buffer[0x34]
u8 encryptedprivatekey[0x20] - the private key returned by KIRK 0xC must be AES encrypted somehow
u8 SHA1hashofmessagetosign[0x14]
memcpy(buffer,encryptedprivatekey,0x20)
memcpy(buffer+0x20,SHA1hashofmessagetosign,0x14)
sceUtilsBufferCopyWithRange(newsig,0x28,buffer,0x34,0x10);
 
newsig will have the r and s values for an ECDSA signature
 
This isn't that useful since it is not clear how to encrypt the private key to sign the message. There are some examples in IDStorage where a pre-encrypted private key and public key pair can be used, but no general cases yet.


With a bit more reading and working with Proxima, we have discovered how to encrypt and decrypt these keys! Below is code:

typedef struct
{
	u8 fuseid[8];	//0
	u8 mesh[0x40];	//0x8
} keygen_data; //0x48
 
u8 g_idstorage_dA_key[] =
{
	0x47, 0x5E, 0x09, 0xF4, 0xA2, 0x37, 0xDA, 0x9B, 
	0xEF, 0xFF, 0x3B, 0xC0, 0x77, 0x14, 0x3D, 0x8A
};
 
void decrypt_kirk10_private(u8 *dA_out, u8 *dA_enc)
{
	int i, k;
	keygen_data keydata;
	u8 subkey_1[0x10], subkey_2[0x10];
	rijndael_ctx aes_ctx;
 
	/* get the fuse id */
	for (i = 0; i < 4; i++)
	{
		keydata.fuseid[3 - i] = ((u8 *)0xBC100090)[i+4];
		keydata.fuseid[7 - i] = ((u8 *)0xBC100090)[i];
	}
 
	/* set encryption key */
	rijndael_set_key(&aes_ctx, g_idstorage_dA_key, 128);
 
	/* set the subkeys */
	for (i = 0; i < 0x10; i++)
	{
		/* set to the fuseid */
		subkey_2[i] = subkey_1[i] = keydata.fuseid[i % 8];
	}
 
	/* do aes crypto */
	for (i = 0; i < 3; i++)
	{
		/* encrypt + decrypt */
		rijndael_encrypt(&aes_ctx, subkey_1, subkey_1);
		rijndael_decrypt(&aes_ctx, subkey_2, subkey_2);
	}
 
	/* set new key */
	rijndael_set_key(&aes_ctx, subkey_1, 128);
 
	/* now lets make the key mesh */
	for (i = 0; i < 3; i++)
	{
		/* do encryption in group of 3 */
		for (k = 0; k < 3; k++)
		{
			/* crypto */
			rijndael_encrypt(&aes_ctx, subkey_2, subkey_2);
		}
 
		/* copy to out block */
		memcpy(&keydata.mesh[i * 0x10], subkey_2, 0x10);
	}
 
	/* set the key to the mesh */
	rijndael_set_key(&aes_ctx, &keydata.mesh[0x20], 128);
 
	/* do the encryption routines for the aes key */
	for (i = 0; i < 2; i++)
	{
		/* encrypt the data */
		rijndael_encrypt(&aes_ctx, &keydata.mesh[0x10], &keydata.mesh[0x10]);
	}
 
	/* set the key to that mesh shit */
	rijndael_set_key(&aes_ctx, &keydata.mesh[0x10], 128);
 
	/* cbc decrypt the dA */
	aes_cbc_decrypt(&aes_ctx, dA_enc, dA_out, 0x20, NULL);
}
 
void encrypt_kirk10_private(u8 *dA_out, u8 *dA_dec)
{
	int i, k;
	keygen_data keydata;
	u8 subkey_1[0x10], subkey_2[0x10];
	rijndael_ctx aes_ctx;
 
	/* get the fuse id */
	for (i = 0; i < 4; i++)
	{
		keydata.fuseid[3 - i] = ((u8 *)0xBC100090)[i+4];
		keydata.fuseid[7 - i] = ((u8 *)0xBC100090)[i];
	}
 
	/* set encryption key */
	rijndael_set_key(&aes_ctx, g_idstorage_dA_key, 128);
 
	/* set the subkeys */
	for (i = 0; i < 0x10; i++)
	{
		/* set to the fuseid */
		subkey_2[i] = subkey_1[i] = keydata.fuseid[i % 8];
	}
 
	/* do aes crypto */
	for (i = 0; i < 3; i++)
	{
		/* encrypt + decrypt */
		rijndael_encrypt(&aes_ctx, subkey_1, subkey_1);
		rijndael_decrypt(&aes_ctx, subkey_2, subkey_2);
	}
 
	/* set new key */
	rijndael_set_key(&aes_ctx, subkey_1, 128);
 
	/* now lets make the key mesh */
	for (i = 0; i < 3; i++)
	{
		/* do encryption in group of 3 */
		for (k = 0; k < 3; k++)
		{
			/* crypto */
			rijndael_encrypt(&aes_ctx, subkey_2, subkey_2);
		}
 
		/* copy to out block */
		memcpy(&keydata.mesh[i * 0x10], subkey_2, 0x10);
	}
 
	/* set the key to the mesh */
	rijndael_set_key(&aes_ctx, &keydata.mesh[0x20], 128);
 
	/* do the encryption routines for the aes key */
	for (i = 0; i < 2; i++)
	{
		/* encrypt the data */
		rijndael_encrypt(&aes_ctx, &keydata.mesh[0x10], &keydata.mesh[0x10]);
	}
 
	/* set the key to that mesh shit */
	rijndael_set_key(&aes_ctx, &keydata.mesh[0x10], 128);
 
	/* cbc encrypt the dA */
	aes_cbc_encrypt(&aes_ctx, dA_dec, dA_out, 0x20, NULL);
}

As you can see, there is common key generation code, you could make it into it’s own subroutine but I’ve laid out the code for clarity.
-Davee

]]> http://lolhax.org/2011/07/06/kirk-0x10-private-key/feed/ 52