Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > General > Decrypting

Reply
 
Thread Tools Search this Thread Display Modes
Old 5th September 2008, 15:33   #81  |  Link
derbeDeus
Registered User
 
Join Date: Mar 2008
Posts: 98
It's amazing the quantity of errors on this thread :P I would expect a certain amount of errors, but this is pure careless.
r29 is sp, so the parameters are passed on the stack, since it is a 32-bit machine, big-endian, the distance between param addresses should be 4.
if key is a pointer, it should be at sp+12

and wtf is this:
Code:
UINT32 *d;
UINT32 *s;
memcpy(d,dst,len);
memcpy(s,src,len)
derbeDeus is offline   Reply With Quote
Old 5th September 2008, 17:33   #82  |  Link
Oopho2ei
Guest
 
Posts: n/a
Quote:
Originally Posted by Disabled View Post
Indeed the LB loaded a wrong adress and after I changed it, the VM works flawless!
Congratulations.
Yes, i will look at the traps now. One question: does this work without overwriting some bytes of the image (00000.svm) with 00/FF prior execution? Or is this required and your machine only runs with the snapshot i provided (posting #67)? If those modifications (hacks ) are indeed required i would have to study the loader too.

Quote:
Originally Posted by Disabled View Post
I can't find a single problem until the 840th cmd is issued, that is trap 520 and after that, things go wrong...
For verification a snapshot before trap_520:
register file: http://uploaded.to/?id=z0msdc
memory snapshot: http://uploaded.to/?id=44w6lq

To continue execution after trap_520 a snapshot directly afterwards:
register file: http://uploaded.to/?id=ljl4an
memory snapshot: http://uploaded.to/?id=sdgznt

Let me know if you need more traces of instruction results. You will probably soon need a longer program counter trace.

Quote:
Originally Posted by derbeDeus View Post
It's amazing the quantity of errors on this thread :P I would expect a certain amount of errors, but this is pure careless.
I'm sorry about the cmd18/cmd19 logfile/trace mistake. It has been corrected in posting #61. I decided not to go to bed although i was dead tired so people would get this one day earlier. I try to provide enough redundancy (like those instruction results, memory dumps, etc) so that the reader can do error detection and correction on it's own. Again: if you find anything please leave a note here or pm me.

Quote:
Originally Posted by derbeDeus View Post
And yes, 110 is TRAP_Aes
Seems to be correct. I have observed the calculation of the round key table using the aes s-box. Sadly i can't find any documentation of the return codes (like 80000001h). Did somebody else find anything?

Last edited by Oopho2ei; 6th September 2008 at 00:29.
  Reply With Quote
Old 6th September 2008, 05:17   #83  |  Link
Disabled
Registered User
 
Join Date: Aug 2004
Posts: 211
Sadly it doesn't work with the 00000.svm, only with the mem_setup.bin. If the first 4 bytes are zeroed as far as I can tell it works the same as the mem_setup.bin, but there are still some more bytes zeroed 0007ece4-0007ed0b to be precise.
The FF differences were due to LB not loading one FF and thus the SDW storing 00s instead of FFs.

On the plus side, if I just ignore trap 110, the VM is in exactly the same state as your dump shows right before trap 520. Same mem, same regs.
So I wonder, what are the traps 110 doing? OK, AES but on what memory are they working? Can't be on that 4MB address space the VM uses can it?
Trap 520 on the other hand changes around 300 bytes of the memory(according to your dump).

With the help of someone I was also able to correct two errors that didn't show up until now, but might have in the future.
Disabled is offline   Reply With Quote
Old 6th September 2008, 08:34   #84  |  Link
sakman
Registered User
 
Join Date: Mar 2007
Posts: 11
Quote:
Originally Posted by Disabled View Post
Sadly it doesn't work with the 00000.svm, only with the mem_setup.bin. If the first 4 bytes are zeroed as far as I can tell it works the same as the mem_setup.bin, but there are still some more bytes zeroed 0007ece4-0007ed0b to be precise.
If you look at the header for 00000.SVM:
42 44 53 56 4D 5F 43 43 01 00 00 00 01 07 D7 0B 06 00 00 00 00 07 EC E4

Coincidence?
sakman is offline   Reply With Quote
Old 6th September 2008, 10:38   #85  |  Link
Oopho2ei
Guest
 
Posts: n/a
Quote:
Originally Posted by Disabled View Post
On the plus side, if I just ignore trap 110, the VM is in exactly the same state as your dump shows right before trap 520. Same mem, same regs. So I wonder, what are the traps 110 doing? OK, AES but on what memory are they working? Can't be on that 4MB address space the VM uses can it?
As you know the traps are executed on the host system so any trap can both change the state of the host system (eg. replace some bytes in the video/audio output of the player) and the state of the guest system. I For obvious reasons i only show you the guest system.

All the trap_110 calls before trap_520 have as last parameter (UINT32 opOrKeyID) values like 5,6,7,8 which are all less than FFF10000h and are therefor according to the patent "player key" (numbers). The trap_aes code and memory is on the host system side so you don't see anything of what is going on there.

Can you check if the first access to r01 after execution of trap_110 is a read or a write access? It would be interesting to know how they evaluate the return code (eg. 80000001h).

Quote:
Originally Posted by Disabled View Post
Trap 520 on the other hand changes around 300 bytes of the memory(according to your dump).
You can check the parameters passed to trap_520 before it is called (r29 acts as stack pointer -> see posting #34). Maybe you can find the length and address of the difference in the memory snapshots in those parameters.

Quote:
Originally Posted by sakman View Post
If you look at the header for 00000.SVM:
42 44 53 56 4D 5F 43 43 01 00 00 00 01 07 D7 0B 06 00 00 00 00 07 EC E4
You are right. This is indeed interesting. I will check what code is accessing that area of the header.

edit: i have now checked how a trap call changes the watchdog timer: every trap call resets the timer back to 7FFFFFFFh. I have corrected this in posting #25.

Last edited by Oopho2ei; 6th September 2008 at 13:01.
  Reply With Quote
Old 6th September 2008, 14:21   #86  |  Link
Disabled
Registered User
 
Join Date: Aug 2004
Posts: 211
These are the cmds before Trap 520:
Quote:
832 19FE0 E3FD0000 SDW R31(0x00000001), R29(0x001EFF64), 0x0000
833 19FE4 E3FD0004 SDW R31(0x00000001), R29(0x001EFF64), 0x0004
834 19FE8 C0200000 LHI 0x0000
835 19FEC 642121A0 ADDI R1(0x00000000), R1(0x00000000), 0x21A0
836 19FF0 E03D0008 SDW R1(0x000021A0), R29(0x001EFF64), 0x0008
837 19FF4 603EFFF4 ADDIE R1(0x000021A0), R30(0x001EFF90), -0x000C
838 19FF8 E03D000C SDW R1(0x001EFF84), R29(0x001EFF64), 0x000C
839 19FFC B4000BFC JAL 0x0BFC
840 1ABFC E4000520 TRAP 0x0520
So it seems it has 4 arguments. The first two parameters passed have a value of 0x01, the third is the destination address where the data is overwritten, the fourth is a pointer where a return value is written. I can't find anything that relate to the length of the data changed (284 bytes plus one byte at the return address).

About Trap 110, the two times it is executed, R1 is overwritten directly after that.

*edit* I restructured the output a little (see above) so grab the new version here. For first timers I packed the source, the (modified) mem file and the debug traces into one zip. Just unzip, compile and run the output. Then you get the output trace (pipe it into a file) and dump.txt (I should change the extension) of the mem right before trap 520.
*edit2* I rewrote the dasm function, so if you find an error in the disassembled commands (like the LHI missing its register in the trace above) please give me a note.

*edit* forgot the zip

*edit2* I updated the bdvm.c in the source only link. If you download the full package, make sure you grab this version as well.

Last edited by Disabled; 7th September 2008 at 03:16.
Disabled is offline   Reply With Quote
Old 6th September 2008, 15:40   #87  |  Link
ala42
Registered User
 
ala42's Avatar
 
Join Date: Aug 2008
Posts: 19
You forgot to add PC in the JAL instruction.
ala42 is offline   Reply With Quote
Old 6th September 2008, 15:47   #88  |  Link
Disabled
Registered User
 
Join Date: Aug 2004
Posts: 211
Youre right, right now the jumps are decoded relative and the PC is not added. That was already on my todo list, but I forgot to mention it. Thanks for reminding me.
Disabled is offline   Reply With Quote
Old 6th September 2008, 16:51   #89  |  Link
sakman
Registered User
 
Join Date: Mar 2007
Posts: 11
Quote:
Originally Posted by Oopho2ei View Post
You are right. This is indeed interesting. I will check what code is accessing that area of the header.
Interesting to see what is in those 28h bytes that are not copied at the end of each BDSVM_CC section. The size of the footer seems to be consistent across each of the 200000h sections. Header 18h bytes, Footer 28h bytes.

0x18+0x7ECE4+0x28=0x7ED24 end of 1st section.
Other sections: 0x18+0x1FFFC0+0x28=0x200000.

I looked at a different 00000.svm and the footer was the same size 28h bytes.
sakman is offline   Reply With Quote
Old 6th September 2008, 17:48   #90  |  Link
schluppo
Guest
 
Posts: n/a
Trap 520 should be one of these two:

UINT32 TRAP_DeviceDiscovery(UINT32 dev, UINT32 qID, UINT8 *buf, UINT32 *len);
UINT32 TRAP_DeviceAccess(UINT32 dev, UINT32 opID, UINT8 *buf, UINT32 *len);

These are the only two traps with four parameters which don't have pointers as first two parameters (apart from TRAP_Mediawrite which wouldn't make much sense so early in execution).

My guess is that it's TRAP_DeviceDiscovery (makes sense to first discover the device before it's accessed). With this trap it's for instance possible to get "decryption keys or other cryptographic parameters" from the device.

For TRAP_DeviceDiscovery, first parameter (1) is the device number, second parameter (1) is the question id. The answer to the question is put to adress in the third parameter (0x21A0). Furthermore:

"Calling routines should pass the maximum length (in bytes) of the buffer pointed to by buf as the location indexed by len. The value returned in len will indicate the number of bytes actually written to buf". Len points to 0x1EFF84 in the above trace (the value at this position should be around 284 / 0x11C after execution).

TRAP_DeviceAccess specification is similar, it just takes an operation number instead of a question number.

By the way: In order to be able to emulate all the traps as good as possible, it would be nice to get ahold of "trap traces". By that i mean the values of (some of) the registers and (part of) the memory directly before and after each execution of a trap with a specific numer.

On more thing: the return values of the traps 110 and 520 seem to be just status flags so far.


On another note, Oopho says, that trap 110 is called several times, whereas according to Disabled, it's just called twice. Contradiction?
  Reply With Quote
Old 6th September 2008, 17:55   #91  |  Link
chavonbravo
Registered User
 
Join Date: Aug 2007
Posts: 17
Quote:
Originally Posted by Oopho2ei View Post
Seems to be correct. I have observed the calculation of the round key table using the aes s-box. Sadly i can't find any documentation of the return codes (like 80000001h). Did somebody else find anything?
Sounds like it's simply a status return value denoting that everything went ok. On patent description:

"Most of the exemplary TRAPs return a status value (e.g., a constant STATUS_OK that indicates success, or a value indicating an error condition, or that otherwise describes the result or state of the system or operation). For brevity, the contents of the return value are generally omitted in the TRAP descriptions below if the value is simply a status value. Some TRAPs do not return any status value, but may fail (e.g., if given illegal input parameters), in which case content code may need to ensure that appropriate inputs are provided and/or verify that the operation completed as expected."

On section 0130 of patent description it describes the aes trap a bit also, it seems that we'll have to find out all the aes player keys for whatever player will be emulated.

Also, to help map the correct trap calls, this will help:

"To invoke a TRAP, the caller first pushes each of the parameters (starting with the rightmost parameter in the prototype definition)"

So we can just look at the values pushed, the order, then go to patent description and find out much easier.

edit:

Though from what schluppo derived about trap 520, it seems the order of parameters pushed is really left to right in the prototype definitions?? There's no list of qID's in the description which would have helped.

Last edited by chavonbravo; 6th September 2008 at 18:49.
chavonbravo is offline   Reply With Quote
Old 6th September 2008, 18:07   #92  |  Link
Disabled
Registered User
 
Join Date: Aug 2004
Posts: 211
In my trace (and the PC is always correct according to the PC trace) there are only two calls to trap 110 before the first trap 520.

The address in the 4th parameter indeed contains 0x11c after the trap 520 was executed. I'm sorry I didn't get it in the first run, I think I was confused by comparing the wrong dumps.
Before the trap it contains 0x140.
Disabled is offline   Reply With Quote
Old 6th September 2008, 21:13   #93  |  Link
Oopho2ei
Guest
 
Posts: n/a
Ok i have studied the path between 00000.svm and mem_setup.bin. To load the 00000.svm do the following:

1. parse the header: bytes 0x14-0x17 make up a length 'len' stored as big endian (thanks to sakman for the hint )
2. load the section from 0x18 to len+0x18-1 of 00000.svm into memory (and convert from big endian to little endian)
3. overwrite the first 0xFFF bytes of the loaded section with zeros
4. done. Now start execution at 0x1000

It took me a long time to figure out these simple steps. Hope it was worth it.

Quote:
Originally Posted by sakman View Post
Interesting to see what is in those 28h bytes that are not copied at the end of each BDSVM_CC section.
I believe it's a checksum or signature. Maybe if the signature/checksum fails the player looks at the copy in the backup directory. It currently looks like it is just being ignored.

Quote:
Originally Posted by schluppo View Post
My guess is that it's TRAP_DeviceDiscovery (makes sense to first discover the device before it's accessed).
That is my guess too. I update the table in posting #34 regularly

Quote:
Originally Posted by schluppo View Post
On another note, Oopho says, that trap 110 is called several times, whereas according to Disabled, it's just called twice. Contradiction?
By several times i mean more than once. It's probably called very often in relation to other traps because part of the program/data is encrypted and needs to be decrypted first. I believe we are after 840 instructions still in the initialization phase.

Quote:
Originally Posted by schluppo View Post
By the way: In order to be able to emulate all the traps as good as possible, it would be nice to get ahold of "trap traces". By that i mean the values of (some of) the registers and (part of) the memory directly before and after each execution of a trap with a specific numer.
I know but i can't just give you snapshots of the host system (with the embedded guest system). It would be easy to see from whatever player this was taken from. And i obviously can't simply take snapshots of two different players and zero out differences. Furthermore it is difficult to make and use these snapshots of the host system: the guest system is single threaded the host system is (usually) not.
I will trace the data flow through the traps and report when i found something interesting. If you need specific details to continue your research/experiments just tell me.

Anyway i have the feeling that people (none slysoft employees) like 'derbeDeus' know already very well how all these traps work. So maybe invite them for a drink.

Last edited by Oopho2ei; 7th September 2008 at 11:14.
  Reply With Quote
Old 7th September 2008, 01:40   #94  |  Link
Oopho2ei
Guest
 
Posts: n/a
I would like to document the traps like this if nobody has a better idea. Instead of pseudocode or long confusing descriptions i would use low level C notation:
Code:
//
// UINT32 TRAP_Aes(UINT8 *dst, UINT8 *src, UINT32 len, UINT8 *key, UINT32 opOrKeyID) 
//

UINT32 TRAP_Aes_Handler(UINT8 *vm_mem, UINT32 sp) // sp = stack pointer
{
  UINT32 dest, src, len, key, opOrKeyID;
  UINT32 status_code;

  /* read parameter */

  // enforce dword alignment when reading the parameter
  dest      = *(vm_mem + ((sp + 0x00) & 0x3FFFFC)); // destination pointer
  src       = *(vm_mem + ((sp + 0x04) & 0x3FFFFC)); // source pointer
  len       = *(vm_mem + ((sp + 0x08) & 0x3FFFFC)); // length value
  key       = *(vm_mem + ((sp + 0x0C) & 0x3FFFFC)); // key pointer
  opOrKeyID = *(vm_mem + ((sp + 0x10) & 0x3FFFFC)); // operation number or 

  status_code = TRAP_Aes(vm_mem, dst, src, len, key, opOrKeyID);

  switch (status_code)
  {
    case 0x80FFFFFF: break; // TODO: ?
    case 0x80000002: break; // TODO: ?
    case 0x80000001: break; // TODO: ?
  }

  return status_code;
}

UINT32 TRAP_Aes(UINT8 *vm_mem, UINT32 dst, UINT32 src, UINT32 len, UINT32 key, UINT32 opOrKeyID);
{
  UINT32 tmp;
  
  tmp = 192*len+408; // store this somewhere in memory
  
  if (dst >= 0x400000)
  {
    // TODO: ?
  }
  
  // TODO: ?

  if (opOrKeyID >= 0xFFF10000)
  {
    // opOrKeyID = operation code
    switch (opOrKeyID)
    {
      case 0xFFF10000: // TODO: AES_ECB_ENCRYPT
      case 0xFFF10001: // TODO: AES_ECB_DECRYPT
      default: // TODO: AES_ECB_DECRYPT_MEDIA_KEY
              return 0x80000001;
    }
  } else {

    // opOrKeyID = player key number
    if (opOrKeyID > 6)
    {
      // TODO: ?
      return 0x80000001;
    } else {
      // TODO: ?
    }

  }

}

void main()
{
  UINT8 vm_mem[0x400000]; // 4MB memory
  UINT32 reg[32]; // register file

  reg[01] = TRAP_Aes_Handler(&vm_mem, reg[29]);

}
You should use equivalent high level constructs of your programming language.

Last edited by Oopho2ei; 7th September 2008 at 11:56.
  Reply With Quote
Old 7th September 2008, 03:40   #95  |  Link
Disabled
Registered User
 
Join Date: Aug 2004
Posts: 211
Quote:
Originally Posted by Oopho2ei View Post
Ok i have studied the path between 00000.svm and mem_setup.bin. To load the 00000.svm do the following:

1. parse the header: bytes 0x14-0x17 make up a length 'len' stored as big endian (thanks to sakman for the hint )
2. load the section from 0x18 to len+0x18 of 00000.svm into memory (and convert from big endian to little endian)
3. overwrite the first 0xFFF bytes of the loaded section with zeros
4. done. Now start execution at 0x1000
I somehow don't think this is right. 0x14-0x17 contain the start address where to zero memory.

The header is
Quote:
42 44 53 56 4D 5F 43 43 01 00 00 00 01 07 D7 0B
06 00 00 00 00 07 EC E4
. 0x7ece4 is the correct start address, the length is (at least) 0x28 and those bytes have to be zeroed. I can't find the length in the header, but the next bytes after 0x7ece4 are zero anyway.
I just cross checked this with the second segment, and there the start (0x14-0x17) points to the very end of the segment (0x28 bytes to end, thats the signature/footer?), so there is nothing to be zeroed.

The first 4 bytes after the header are "B3 FF FF FC" and have to be zeroed as well. I don't know if this is neccesary with other segments, as I don't have traces of those. Also it doesn't seem to me those bytes have any information in them (They decode to a J #0000, so seem to be code and not addresses...)

*edit* Does anyone have ideas how to administrate this project? I have the feeling that others could greatly improve my source but don't because they think they would interfere with my development process. Any ideas about setting up an svn or something? Sourceforge or the like? Or do you think this is a little over the top and doesn't need more than posting sources every now and then?

Last edited by Disabled; 7th September 2008 at 03:52.
Disabled is offline   Reply With Quote
Old 7th September 2008, 09:35   #96  |  Link
evdberg
Registered User
 
Join Date: Dec 2006
Posts: 202
I know I am nitpicking, but when in C a variable is a pointer to an object, then adding something to this variable is automatically multiplied by the sizeof the object the pointer is pointing to. In this case vm_mem++ will increase vm_mem with 4, not by 1. In other words, it's better to keep all pointers to data (vm) memory as a byte pointer.
__________________
Developer DVD2one - http://www.dvd2one.com/
evdberg is offline   Reply With Quote
Old 7th September 2008, 10:59   #97  |  Link
Oopho2ei
Guest
 
Posts: n/a
Quote:
Originally Posted by Disabled View Post
I somehow don't think this is right. 0x14-0x17 contain the start address where to zero memory.
Those bytes are already zeroed during your memory allocation process. You don't load the full first section of 00000.svm only to overwrite the parts with zeros you shouldn't have loaded in the first place. According to my description len+1 bytes were copied so i added a '-1'. Did you mean that?

Quote:
Originally Posted by Disabled View Post
The first 4 bytes after the header are "B3 FF FF FC" and have to be zeroed as well. I don't know if this is neccesary with other segments, as I don't have traces of those. Also it doesn't seem to me those bytes have any information in them (They decode to a J #0000, so seem to be code and not addresses...)
The other segments (except the first two of 000002.svm) are encrypted or just filled with random data. We currently can't see the internal structure. (remember i uploaded the beginning of (decrypted) section 2 of file 000001.svm in posting #19). For now only zero the beginning of the very first section of 00000.svm.

Quote:
Originally Posted by Disabled View Post
*edit* Does anyone have ideas how to administrate this project? I have the feeling that others could greatly improve my source but don't because they think they would interfere with my development process. Any ideas about setting up an svn or something? Sourceforge or the like? Or do you think this is a little over the top and doesn't need more than posting sources every now and then?
svn/cvs/git is really needed.

Quote:
Originally Posted by evdberg View Post
I know I am nitpicking, but when in C a variable is a pointer to an object, then adding something to this variable is automatically multiplied by the sizeof the object the pointer is pointing to. In this case vm_mem++ will increase vm_mem with 4, not by 1. In other words, it's better to keep all pointers to data (vm) memory as a byte pointer.
I declared vm_mem as UINT8 in the main() but now i see the "UINT32 *vm_mem" in the TRAP_Aes_Handler declaration. Thank you.
There would also be a problem if the parameters are not stored as little endian.

edit: regarding the mapping "trap_number -> trap_name". When you compare my little trap_number list in posting #34 with the list of trap_names made by schluppo: http://uploaded.to/?id=tb40lb in posting #74 you might notice that there are four 01XX traps which make up a group containing trap_aes. Now when you look at the trap_name list from schluppo you will see that he has also put trap_aes in a group of four "crypto traps". So one could think that all the other 01XX traps are crypto traps as well. The same applies to traps_02XX and traps_05XX where we already know a group member. Note that my list of trap numbers is probably not complete as i have only written down trap numbers which are used or at least referred to by the vm program on this blue ray disc i use. I will try to get a full list now.

edit: i believe return code 80FFFFFF indicates an error like usually return(-1) so maybe interpret the lower 24 bit as signed number.

edit:
Code:
000010 = void TRAP_Finished();
000020 2 parameters -> ?
000110 = UINT32 TRAP_Aes(UINT8 *dst, UINT8 *src, UINT32 len, UINT8 *key, UINT32 opOrKeyID);
000120 = UINT32 TRAP_PrivateKey(UINT32 keyID, UINT8 *dst, UINT8 *src, UINT32 srcLen, UINT32 controlWord);
000130 = UINT32 TRAP_Random(UINT8 *dst, UINT32 len);
000140 = UINT32 TRAP_Sha(UINT8 *dst, UINT8 *src, UINT32 len, UINT32 op); 
000210 = UINT32 TRAP_AddWithCarry(UINT32 *dst, UINT32 *src, UINT32 len);
000220 = UINT32 TRAP_MultiplyWithRipple(UINT32 *dst, UINT32 *src, UINT32 len, UINT32 multiplicand);
000230 = UINT32 TRAP_XorBlock(UINT32 *dst, UINT32 *src, UINT32 len); 
000310 = UINT32 TRAP_Memmove(UINT8 *dst, UINT8 *src, UINT32 len);
000320 = UINT32 TRAP_MemSearch(UINT8 *Region, UINT32 RegionLen, UINT8 *SearchData, UINT32 SearchDataLen, UINT32 *Dst);
000330 = UINT32 TRAP_Memset(UINT8 *dst, UINT8 fillvalue, UINT32 len);
000410 = UINT32 TRAP-SlotAttach(UINT32 slot, UINT32 codeLen);
000420 = UINT32 TRAP-SlotRead(UINT8 *dst, UINT32 slot);
000430 = UINT32 TRAP_SlotWrite(UINT8 *newContents);
000510 = UINT32 TRAP_DeviceAccess(UINT32 dev, UINT32 opID, UINT8 *buf); 
000520 = UINT32 TRAP_DeviceDiscovery(UINT32 dev, UINT32 qID, UINT8 *buf, UINT32 *len);
000530 = UINT32 TRAP_DiscoveryRAM(UINT32 unknown, UINT32 dst, UINT32 len);
000540 = UINT32 TRAP_MediaReadFile(UINT8 *FileName, UINT32 SectionNumber, UINT32 Unknown, UINT32 *len, UINT8 *dst);
000550 = UINT32 TRAP_MediaSHAFileHash(UINT8 *FileName, UINT32 FileNameLen, UINT32 FileOffsetHigh, UINT32 FileOffsetLow, UINT32 *len, UINT8 *dst);
000560 = UINT32 TRAP_RunNative(UINT8 *signature, UINT32 sigLen, UINT8 *code, UINT32 codeLen);
000570 ? nop/vendor specific?
008010 = UINT32 TRAP_DebugLog(UINT8 *txt, UINT32 len);
008020 ?
008030 ?
Note this is a guess. I would have to verify this. But this doesn't seem to be coincidence.

Last edited by Oopho2ei; 4th October 2008 at 23:32.
  Reply With Quote
Old 8th September 2008, 16:32   #98  |  Link
Disabled
Registered User
 
Join Date: Aug 2004
Posts: 211
Quote:
Originally Posted by Oopho2ei View Post
the parts with zeros you shouldn't have loaded in the first place. According to my description len+1 bytes were copied so i added a '-1'. Did you mean that?
It took some time (that I don't have much right now) and a few rereads to understand your description. Everything after the address in 0x14-0x17 is zeroed (ie. not loaded), so I just load from 0x18 and stop at the address in the header (+0x18-1).

Apart from that and a few technical things, is there anything I can implement in the VM right now? I could do a few traps that seem to not need any further documentation like TRAP_XorBlock, TRAP_Memmove, TRAP_Memset, TRAP_Random and TRAP_Memsearch or TRAP_Aes perhaps. I was thinking about using this lib for AES decryption or does anyone have better ideas? (Of course TRAP_Aes isn't fully documented, but the main de/encryption could be implemented).
Disabled is offline   Reply With Quote
Old 8th September 2008, 17:20   #99  |  Link
Oopho2ei
Guest
 
Posts: n/a
Quote:
Originally Posted by Disabled View Post
It took some time (that I don't have much right now) and a few rereads to understand your description. Everything after the address in 0x14-0x17 is zeroed (ie. not loaded), so I just load from 0x18 and stop at the address in the header (+0x18-1).
again as sample C code:

Code:
0. some declarations:
UNIT32 mem_size = 0x400000; 
UNIT32 len;
UNIT8 *p;

1. UNIT8 vm_mem[mem_size]; // allocate memory

2. for (i=0; i<vm_mem; i++) vm_mem[i] = 0; // zero memory
3. // open file 00000.svm and let p be a pointer pointing to the beginning of the file
4. // len = bytes 0x14-0x17 interpreted as UINT32 in big endian
5. for (i=0; i<len; i++) vm_mem[i ^ 0x03] = *(p + 0x18 + i) // load the section (as little endian)
6. // close file
7. for (i=0; i<0x1000; i++) vm_mem[i] = 0; // erase the first 0x1000 bytes

8. now zero all registers, set watchdog to 0x7FFFFFFF, pc to 0x1000 and start execution.
In general if something is unclear just ask for an example. It is hard to see where you and other people get confused.

Quote:
Originally Posted by Disabled View Post
Apart from that and a few technical things, is there anything I can implement in the VM right now? I could do a few traps that seem to not need any further documentation like TRAP_XorBlock, TRAP_Memmove, TRAP_Memset, TRAP_Random and TRAP_Memsearch or TRAP_Aes perhaps. I was thinking about using this lib for AES decryption or does anyone have better ideas? (Of course TRAP_Aes isn't fully documented, but the main de/encryption could be implemented).
Yes please start implementing these traps. Maybe use a separate file for every trap group (crypto traps, mem traps, ...).

Has anyone setup an sourceforge account for this project yet? Otherwise i would create one.

Last edited by Oopho2ei; 8th September 2008 at 17:25.
  Reply With Quote
Old 8th September 2008, 17:52   #100  |  Link
Disabled
Registered User
 
Join Date: Aug 2004
Posts: 211
Quote:
Originally Posted by Oopho2ei View Post
again as sample C code:

Code:
7. for (i=0; i<0x1000; i++) vm_mem[i] = 0; // erase the first 0x1000 bytes
Thats a new information is it? And this has to be done for every section? I remember you writing to only erase the beginning in the first section?!
Quote:
Yes please start implementing these traps. Maybe use a separate file for every trap group (crypto traps, mem traps, ...).
Will do if I find the time.
Quote:
Has anyone setup an sourceforge account for this project yet? Otherwise i would create one.
I don't think so, please do if you find the time. I hope this will ease the project administration and source distribution. I feel there are many brilliant brains watching this thread but not giving as much input as they could, perhaps because they don't want to be contributing to a project that might provide problems with their local laws...
Disabled is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 14:26.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2023, vBulletin Solutions Inc.