|
|||
|
|
|||
|
|
 |
 |
 |
|
 |
04-24-2007
|
||||
|
||||
|
Quote:
That's why it was called an interim version. I have a couple more things which I forget to mention / fix / implement in last 2 interim versions: 1. The length calculation on results.txt is incorrect! (see also bellow attached results-1.txt and resultsOK.txt for comparison). I've already amended that in my 0.3.3 version here but you can do in yours as well. Just amend the following line: Code:
length = endaddr - straddr; Code:
length = endaddr - straddr + 1; I was trying to amend that but unsuccessfully so far so I've ended with putting the fixed values back to the source on both places where the device name is "generated". Optionally - it could be sorted by using the another command line parameter to switch between the default and requested SDx device but I'd prefer to avoid that. |
 |
 |
 |
|
|
|
|
|
04-24-2007
|
||||
|
||||
|
Quote:
The seek part of code is bugged and it's now amended in above posted version 0.3.2 :Important We should somehow merge our current latest version, test the final product and from now on try release only the "official" version. But at least I've dusted a bit my C skills and I have now better understanding of how the program works instead of being just pure consumer of somebody's products ... :grin: OK - I've just found out that you've actually fixed already both "length-1" and seek bugs so ... :hitw :hitw :hitw Two more quick questions: 1. I believe that it's not necessary anymore to specify -lgmp during compile? 2. I suppose you're using dd for making the images of the disk?
Last edited by GrandpaHomer; 04-24-2007 at 04:44 PM.
Reason: Automerged Doublepost
|
|
|
|
|
|
|
|
|
04-24-2007
|
||||
|
||||
|
Quote:
On the sysfs device size file, there was actually some bad char pointer arithmetic that was causing it. I had forgotten to include an extra byte for the terminating NULL character, which I changed in the 0.4.1 release. I actually came across the same problem with Code:
/sys/block/sdf/sys/block//size Code:
# ./scan -hsdf Quote:
But maybe, just maybe, they are using a HUGE block size of 64K. Anyway, I am sorry if I had people's hopes up. Will try to come up with better news later.
Last edited by HanSooloo; 04-25-2007 at 01:44 AM.
Reason: Automerged Doublepost
|
|
|
|
|
|
|
|
|
04-27-2007
|
||||
|
||||
|
I've used 2 of the smallest hard drive the PS3 can still handle - 2.6 GB & 3.2 GB. It's optimal due to the faster scanning and imaging and less disk space to go through when you're looking for some specific signatures / data. I've performed various tests resulting in different images / scan results. Each disk went through 5 stages described bellow: 1. Wiped / zeroed - called Init0 (there is no scan neither image as far as it's simply full of zeroes). 2. Initialization / formating by PS3 up to the prompt "Press x to restart". At this point the PS3 was powered off by the back power switch! (Of course AFTER all the disk activity finished) - called Init1. 3. The same like in point 2 but this time the PS3 was shut down using the front panel power button. There is definitely some disk activity AFTER the power button is pressed but both default scans shows the same results so we need to compare the whole images to seek differences - called Init2. 4.The PS3 is restarted using the x as prompted and SWITCHED OFF at the moment when the XMB shows up and the start up sound finish. It needs to be BEFORE the ps3 will connect online - I've also disconnected the network cable for that - called Init3. 5. The PS3 is restarted using the x as prompted and let to connect online then switched off using the front panel power button - called Init4. There are clear differences between Init2 and Init3 as well as between Init3 and Init4. Also - apparently due to the limited space on the hard drive - the PS3 will actually (despite the initial formating without any errors) not start up correctly with 2.6 GB hard drive ... :Important It will "fiddle" with the disk for a while (which results in even longer scan results in Init3 than for 3.2 GB drive) and then simply beep 3 times and shut itself down to "red flashing mode" ... :eek2 This is also the reason why there is no Init4 scan result for 2.6 GB drive. >HanSooloo: Another couple of additions to scan program: 1. Can you implement the -c command line from my last version? 2. Also - it would be useful to include in the results file the first 16 bytes of every reported block (especially when you're looking for NOT matching signatures). 3. And finally - as already mentioned before) - the size of the drive. I'll finish the scan of remaining drives and post result here as well. As agreed it will be the "Init2" type. Then I'm heading toward filling up the drives (mainly the smallest ones) with some pre-defined files and I'll be looking for them in the images. |
|
|
|
|
|
|
|
|
04-27-2007
|
||||
|
||||
|
I have a couple of questions about the implementation and would like to talk to you live. If you can drop by EFNet, msg me (HanSooloo). |
|
|
|
|
ScanHdd Version 0.4.2 |
|
|
|
|
04-27-2007
|
||||
|
||||
ScanHdd Version 0.4.2
2007-04-27 0.4.2 Han Sooloo, GranpaHomer > Added new parameters based on feedback from GrandpaHomer and changed a number of the old parameters -s This parameter now tells the program on how to proceed after it dumps all the summary information to the screen 0: Do not start, 1: Start, 2: wait for a "y" from stdin Remember that this one used to take a CSV list of scan signature bytes -t This parameter now takes a file name as input. This file is a binary file with the scan signature in it. -r File name where "results.txt" should be directed. |
|
|
|
|
|
|
|
|
04-28-2007
|
||||
|
||||
|
Quote:
I'm having some issues with 0.4.2: 1. Like the help but it messed up all my scripts as far as I'm using the scan mainly without any params ... :tongue2 So - I suggest to put help on "standard" --help option ... :Important 2. For some reason - the scan now get stuck on "0s : harddisk position is : 0.00" and result.txt is completely empty, not even column's headings ... :eek2 :?? (it WILL read the first batch of data to buffer and then freeze) This only happen when default sig is used / -t is not specified! 3. Also - I'd suggest to change the default value for -s to 2. 4. It's also a bit slower now due to the more code and multiply conditions in the main loop. We may need to look for some code optimization / multipass scan as discussed ... and some additions: 5. Can we add also the program version in the results.txt after the date / time? (Maybe also Moon phase, local weather, NASDAQ ... :grin: :grin: ) 6. As discussed as well - including of first 16 bytes of new block - preferably both in hexa and ASCII (printable) 7. Counting the result lines and both mark then in the result file as well as report the number of results after scan will finish: Code:
420s : Scan harddisk analysis finished. 8 results found Code:
Nr. Data Start Address Data End Address Data Length First 16 bytes ASCII 0001 0000000000000000 |
|
|
|
|
|
|
|
|
04-28-2007
|
||||
|
||||
|
Oh - there is also something funny about the hddcntr display - at least I hope it's just the formating (the buffer size is set to 111000000): Code:
153s : harddisk position is : 999000000.00 168s : harddisk position is : 1110000000.00 182s : harddisk position is : 1220999936.00 197s : harddisk position is : 1332000000.00 212s : harddisk position is : 1443000064.00 227s : harddisk position is : 1554000000.00 242s : harddisk position is : 1664999936.00 257s : harddisk position is : 1776000000.00 273s : harddisk position is : 1887000064.00 288s : harddisk position is : 1998000000.00 303s : harddisk position is : 2108999936.00 319s : harddisk position is : 2220000000.00 334s : harddisk position is : 2331000064.00 350s : harddisk position is : 2441999872.00 367s : harddisk position is : 2552999936.00 383s : harddisk position is : 2664000000.00 399s : harddisk position is : 2775000064.00 416s : harddisk position is : 2886000128.00 432s : harddisk position is : 2996999936.00 438s : harddisk position is : 3108000000.00 But - the biggest problem - the results seems to be all messed up as well ... :Important As far as default sig does not work I've used the (attached) zero.bin file. See results for 0.4.1 and 0.4.2 ... :eek2 (0.4.1 is the same as 3G2Init4 from my last results post). Also - as mentioned before - the main loop is now 12.22% slower. No big deal so far ... To all others - I suggest to use 0.4.1 for now till we'll manage to iron out the 0.4.2 version ... :smilew |
|
|
|
|
ScanHdd Version 0.4.3 |
|
|
|
|
04-29-2007
|
||||
|
||||
|
ScanHdd Version 0.4.3
The bad hdd buffer counter bug is fixed. Floating point display issue is still there. Don't know about the performance, but everything else is working now. 2007-04-29 0.4.3 Han Sooloo > A bug with the hdd buffer counter not being incremented has been fixed. The variable was not being set properly during the initialization section of the code. Thanks (again) to GrandpaHomer for pointing this out. > There is a known issue at the moment, where when the hdd counter is being incremented, sometimes the displayed value is in some weird floating point format (e.g., 1119999996.00). This needs to be investigated. But regardless, the code is counting in normal decimal form; it's just the fprintf() display that is wrong. |
|
|
|
|
|
|
|
|
04-29-2007
|
||||
|
||||
|
Thanks for the update. I've done a couple of tests with 0.4.4 and here are the results / comments: 1. The printing of the harddisk position during scan seems to be fixed now. 2. The initial seek is still messing the whole scan up if the start position is 0. As suggested above - it needs to be performed ONLY when start position > 0. No additions to the wish list this time (only what I've mentioned already in previous posts and chat) - I don't want to "overflow" your todo list ... :grin: |
|
|
|
|
 |
|
| Tags |
| PS3 HDD Contents |
|
|
|
| Thread Tools | |
|
|
Posted 13 hours ago
by
