[anaria]

Originally Posted by jamesst20 I will also provide you something to byte reverse the dump Edit : There you go : http://pastebin.com/QfKc12s3 (I'm not the author, I don't do C but C++). It's poorly written but works Edit 2 : Cleaned a bit the code and made it easier to use. Works with C/C++ by now http://pastebin.com/y20HuRAZ but still dirty Edit 3 : Rewrote it entirely, didn't like the old dirty way. I don't think it's gonna work in C but yeah should be pretty easy to port it for you : http://pastebin.com/6mjZBSWJ Edit 4: On what Platform are you codding for ? I have no such include #include <unistd.h> in Windows

I've started coding on a Mac but my screen is dead so I'm also using cygwin to debug it on a PC, if I've not coded it too badly it should compile easily on any POSIX like platfrom, you may find short notes in earliest posts.
The only thing I've done to have it compile and run easily under windows and not only with cygwin was to redefine the mkdir so it can be built with MinGW32.

[jamesst20]

Originally Posted by anaria I've started coding on a Mac but my screen is dead so I'm also using cygwin to debug it on a PC, if I've not coded it too badly it should compile easily on any POSIX like platfrom, you may find short notes in earliest posts. The only thing I've done to have it compile and run easily under windows nad not only with cygwin was to redefine the mkdir so it can be built with MinGW32.

Alright Have you seen my last edit for the byte reversing? Should be easy for you (hopefully) to port it.

Also, i'm trying to avoid modifying all you have done on NorDumpTool.c. The way I would like it is that everytime you update it, I just need to fully copy/paste your new code from github and if needed I will fix my work wheter you have changed something that require some changes. From that said, would you mind making your code in a way that I just need to call some functions to get the Nor informations? Like a getStatistics() that would return an array [0] --> Bytes '00', [1] --> Bytes 'FF' etc.. or do it the way you wish :P, a isByteReversed(), something for the generic data (a boolean?), anything else needed so I only need to create a header file (.h) to use your class

Thanks you sir and if you disagree, I would understand but keep in mind that would just make everything else simplier after

[anaria]

@jamesst20 , Yep I saw your post and codes, I'll give it a shot a bit later.

I'm in pain reading again and again all NOR offsets and checking if each areas are variable/static data or empty (00 or FF), and make sure the code covers as much as possible of the 16777216 bytes of the NOR, for now even if it checks the most important parts, it in fact checks only 31.81% of pure bytes.

I'll then include a byte swapping routine later but may not include it in the 0.9.6, don't know yet.

And as for the integration of this code in your own, I will not take time to introduce this changes for now, what I was thinking of, was more about having a GUY which knows each options (-P, -F and so on) execute the binary and then parse the output to eventually fill up some fields in the GUI itself, similar to what have been done with the scetool or some others.

I know that I've been too lazy to make it more flexible and only wrote one big C file instead of splitting it in headers and C, I'll do that later which will help you if you want to have only one app instead of a gui calling a binary.

Also if you use GitHub and fork the project you'll get all diff each time I do some changes which will make it definitely easier for you to build your code. Finaly as you can see my app is very basic (read file->do something->printf whatever) and so very simple to adapt those printf into sprintf or anything nicer

[zecoxao]

if i'm not mistaken, the type of byteswap used is byteswap 16 (16 bytes) in that case, naehrwert has published his ps3_hdd POC tool which includes the function in a clean and tidy way of his

lemme see if i can fetch it.

https://dl.dropbox.com/u/35197530/types.h

#include "types.h"

/*! Swap u16 endianness. */
static void _es16_buffer(u8 *buf, u32 length)
{
	u16 *ptr = (u16 *)buf;
	u32 i;

	for(i = 0; i < length/2; i++)
		ptr[i] = _ES16(ptr[i]);
}

[jamesst20]

Originally Posted by anaria @jamesst20 , Yep I saw your post and codes, I'll give it a shot a bit later. I'm in pain reading again and again all NOR offsets and checking if each areas are variable/static data or empty (00 or FF), and make sure the code covers as much as possible of the 16777216 bytes of the NOR, for now even if it checks the most important parts, it in fact checks only 31.81% of pure bytes. I'll then include a byte swapping routine later but may not include it in the 0.9.6, don't know yet. And as for the integration of this code in your own, I will not take time to introduce this changes for now, what I was thinking of, was more about having a GUY which knows each options (-P, -F and so on) execute the binary and then parse the output to eventually fill up some fields in the GUI itself, similar to what have been done with the scetool or some others. I know that I've been too lazy to make it more flexible and only wrote one big C file instead of splitting it in headers and C, I'll do that later which will help you if you want to have only one app instead of a gui calling a binary. Also if you use GitHub and fork the project you'll get all diff each time I do some changes which will make it definitely easier for you to build your code. Finaly as you can see my app is very basic (read file->do something->printf whatever) and so very simple to adapt those printf into sprintf or anything nicer

Alright for this alternative too That would be a lot easier I guess
When you say it only checks for 31.81% of pure bytes, you mean that the rest is what is determined by all of your struct which are assumed ?

[anaria]

@jamesst20 , this current % represent for today what is really read from the dump and checked.
The missing 68.xx % are all part for which I did not finish to write offsets length and so on, like in ros0/1 you have a lot of data but depending if you get a dump from a PS3 under OFW or CFW all can change, and then you can analyse by many ways like doing MD5 if you have a database for each OFW, but for CFW that's no use, so what I'm doing for this is adding routines to read the each ros TOC so I can analyse each files in it or eventually just their MD5 (bad idea if CFW), at least I need to check if there are data where they're supposed to be, it will then increase the % of bytes covered, it may be quite impossible to reach 100%, but what I'm work on is to be sure to meet as close as possible all what guys gave us on the ps3devwiki.

[guerrierodipace]

Originally Posted by anaria @guerrierdipace, below words are not aimed against you, it's a general way of speaking. CUT

I am not sure to understand...english isn't my native language. That code is reversed for my knowledge and published not by me. I just reported here.

[anaria]

Originally Posted by guerrierodipace I am not sure to understand...english isn't my native language. That code is reversed for my knowledge and published not by me. I just reported here.

What I was trying to say is that even if I appreciate your report and I'm happy you did, I'm just worry about seeing a source code if the author did not publish it himself, in other words I do not want to use some code if there is a risk for it to be stolen.

But reverse Engineering is a different thing, if it's the case it can considered differently.

And so as I knew I would write a lot of stuff I wanted first to ensure that you do not take it for yourself, I just got upset after finding some thread in that other forum...

[Dartban214]

I know I sound like an ass but I'd try to create a header file or two(Keeps it nice and neat in my opinion). But VERY interesting....

You have a very good code process(VERY neat). I'm not very good at C but I can understand it with the C++ I know. May have to see if I can convert it later.

[anaria]

Originally Posted by Dartban214 I know I sound like an ass but I'd try to create a header file or two(Keeps it nice and neat in my opinion). But VERY interesting.... You have a very good code process(VERY neat). I'm not very good at C but I can understand it with the C++ I know. May have to see if I can convert it later.

No pb, I welcome all comments.

That's quite interesting, I've always been thinking of C being ten times easier to read than C++, even if you may need more lines in C than C++ to do the same thing!?

I agree that it may be better to split it into .h and .c, but I did not put that on my priority list