Finally handling BD+ (?)

[superman500]

Great job so far!

 105C BC00FFFC BNEZ R0, #1058h

Please look at the pseudocode in posting #24. The program counter is already incremented during the fetch stage so when the execution of the current instruction (in this case 'BNEZ') starts the PC has already been incremented by 4. Like in the old (bad syntax) that would be "BNEZ R0,#(PC+4)-4" So this instruction actually checks if R0 is zero. If it is everything is fine and the next register is checked. If it is not zero then the machine enters a infinite loop in other words halts. The instruction actually is:

105C BC00FFFC BNEZ R0, #105Ch

The same applies to "1018 B0000040 J #1058h" you are always jumping one instruction too short.
If i see more mistakes i will edit this posting. Sorry that the information is scattered all over this thread (and sometimes more confusing than helpful ). Maybe somebody could make a summery.

Originally Posted by Disabled

Another question: In the .svm files, are there just instructions or is there data that has not length%4==0?

When you look at the 00000.svm file from my last posting you will find strings (copyright foo bar...) so yes there is data. I don't know if there is any data which is not dword aligned but remember that every instruction is dword aligned (instruction address = address & 0x3FFFFC. you know). Hope that helps a little.

In posting #25 is a instruction trace starting from 0x1000 (executing that 00000.svm file). You might want to use that too.

Btw i have now added the instruction offsets for the trace between two trap calls (posting #34).

[Disabled]

Originally Posted by Oopho2ei

If it is not zero then the machine enters a infinite loop in other words halts.

And I just thought noone would programm like that... But then everything is clear.

... don't know if there is any data which is not dword aligned but remember that every instruction is word aligned ... Hope that helps a little.

dword would make it quite simple, with word alignement I would have to trace the program flow and ... well I think its pretty hard to make a jump analysis like "BNEZ r1, 2" with r1==0 then I don't know where to continue with the dasm. But that is a problem that occurs anyway when I want to dasm the whole file and I wonder how that would be solved in a professional dasm.

In posting #25 is a instruction trace starting from 0x1000 (executing that 00000.svm file). You might want to use that too.

I will do that! Nice suggestion.

btw: I got a file reader running. I will update the code once I'm a little more sure about its correctness.

Before you invest a lot of effort in static code analysis please keep that in mind:

Originally Posted by http://securityevaluators.com/pdf/spdc_aacs_2005.pdf

Instruction Filter. The Instruction Filter provides a mechanism to protect content code from static disassembly, or to enable device-specific behavior. Prior to executing an instruction, the VM first computes the XOR of the instruction with the current 32-bit Instruction Filter value. Content code may set the value of the Instruction Filter dynamically via the INSTF instruction. The Instruction filter potentially enhances a content creator’s ability to obfuscate code by forcing adversaries to trace the full code execution path rather than disassembling code in a single pass. Instruction filter values may be computed via cryptographic operations, or from device-specific operations, which may require the adversary to correctly emulate this behavior in order to disassemble code.

The instruction filter is currently zero (couldn't observe any other value) but it is unlikely it will stay that way on future releases. So you have to work together with the guys who write the emulator/interpreter.

[Disabled]

Originally Posted by Oopho2ei

Before you invest a lot of effort in static code analysis please keep that in mind:

The instruction filter is currently zero (couldn't observe any other value) but it is unlikely it will stay that way on future releases. So you have to work together with the guys who write the emulator/interpreter.

Ok, then we really can't create a disassembler that way...
perhaps I'll look into the VM the other day as it didn't look too complicated. At least I got started with cpp again and some of my code might proove usefull in the future - at least for me.
*edit* I'll wrap a few things together and release what I have till now in a few minutes...done

"bmnot" has already started with the emulator/interpreter (see posting #23). (I don't know how far he has come.) Now instead of reading the instruction from the file you would get a sequence of (address, instruction) pairs from the emulator. You would take the instruction and place it at the given address in your machine memory. (Same for register and memory accesses.) The memory would slowly be filled with (plain) instructions and data you can analyze.
Anyway one doesn't really have to study every program run by every disc on the virtual machine. Currently it helps to see the dataflow in and out of the trap calls. But beyond that it is probably only useful to analyze exploits used to disable successful emulation. (which might happen a lot in the future if this succeeds).
What is currently needed most is a working emulator. In posting #39 i provided a memory and register file snapshot prior the execution of the first trap command (#110). If anyone makes it that far and the register/memory state of the emulator matches the given snapshot please leave a note here.

[Disabled]

Of course I know about his attempts and I first started with improving it, but as I didn't write c++ code for a long time I started with something that seemed easier to me.
At the end you just can't really code a dasm for these files because as you said its a quite static code analysis and they can make the code non-static. They could even jump twice to a single dword with a different instruction filter and let it do different things. And if the code decrypts itself, dasm is also useless.

So a VM is the only way to go. Of course it can have a debugger that disassembles the current ops, but a static dasm is impossible imo.

*edit* one thing about the traps... we would have to implement them in another way than the vm do we? Or better said: The VM has to know what each trap exactly does and provide (c++)code accordingly does it?

Originally Posted by Disabled

*edit* one thing about the traps... we would have to implement them in another way than the vm do we? Or better said: The VM has to know what each trap exactly does and provide (c++)code accordingly does it?

Yes, the traps are implemented in the host system. They provide the data interface between player (host system) and the program running on the virtual machine (guest system). Please refer to http://securityevaluators.com/pdf/spdc_aacs_2005.pdf section "The SPDC Interface Specification" for details. The traps are described more closely here: http://appft1.uspto.gov/netacgi/nph-...DN/20070033419 (links taken from posting #14 from "chavonbravo")
But before that i would have to figure out the mapping between the trap number and the Trap name assuming they are all listed in that patent above.

[Disabled]

And here I present: An improved draft experimental alpha BDVM!

I can run your dump and the machine shows the same trace as in post #25. That doesn't mean much, as there are no conditional jumps (after I calculate something) in that trace and on the first conditional jump after a calculation it goes in an infinitive loop.
But the basics work - now I (someone) has to debug it.
I used bmnots work as a great start. I hope our developement didn't collide here.
I tried to convert some of his syntax to the new one from post #27 and tried to add the last cmds. That was before I did the dasm, so it added a lot of clutter, as I did some things I didn't really understand. I will investigate into that later.

Now the dasm is back, to tell us what happens. So here is the trace of the file:

  1000        0 NOP
  1004        0 NOP
  1008        0 NOP
  100C        0 NOP
  1010        0 NOP
  1014        0 NOP
  1018 B0000040 J #105Ch
  105C BC00FFFC BNEZ R0, #105Ch
  1060 BC01FFFC BNEZ R1, #1060h
  1064 BC02FFFC BNEZ R2, #1064h
  1068 BC03FFFC BNEZ R3, #1068h
  106C BC04FFFC BNEZ R4, #106Ch
  1070 BC05FFFC BNEZ R5, #1070h
  1074 BC06FFFC BNEZ R6, #1074h
  1078 BC07FFFC BNEZ R7, #1078h
  107C BC08FFFC BNEZ R8, #107Ch
  1080 BC09FFFC BNEZ R9, #1080h
  1084 BC0AFFFC BNEZ R10, #1084h
  1088 BC0BFFFC BNEZ R11, #1088h
  108C BC0CFFFC BNEZ R12, #108Ch
  1090 BC0DFFFC BNEZ R13, #1090h
  1094 BC0EFFFC BNEZ R14, #1094h
  1098 BC0FFFFC BNEZ R15, #1098h
  109C BC10FFFC BNEZ R16, #109Ch
  10A0 BC11FFFC BNEZ R17, #10A0h
  10A4 BC12FFFC BNEZ R18, #10A4h
  10A8 BC13FFFC BNEZ R19, #10A8h
  10AC BC14FFFC BNEZ R20, #10ACh
  10B0 BC15FFFC BNEZ R21, #10B0h
  10B4 BC16FFFC BNEZ R22, #10B4h
  10B8 BC17FFFC BNEZ R23, #10B8h
  10BC BC18FFFC BNEZ R24, #10BCh
  10C0 BC19FFFC BNEZ R25, #10C0h
  10C4 BC1AFFFC BNEZ R26, #10C4h
  10C8 BC1BFFFC BNEZ R27, #10C8h
  10CC BC1CFFFC BNEZ R28, #10CCh
  10D0 BC1DFFFC BNEZ R29, #10D0h
  10D4 BC1EFFFC BNEZ R30, #10D4h
  10D8 BC1FFFFC BNEZ R31, #10D8h
  10DC C3A00000 LHI R29, R0, #0h
  10E0 67BD115C ADDI R29, R29, #115Ch
  10E4 C3800000 LHI R28, R0, #0h
  10E8 679C1000 ADDI R28, R28, #1000h
  10EC D7BD0000 LDW R29, R29, #0h
  10F0 E3BC0000 SDW R29, R28, #0h
  10F4 D7A10000 LDW R29, R1, #0h
  10F8 C3A0001F LHI R29, R0, #1Fh
  10FC 67BDFFFC ADDI R29, R29, #FFFCh
  1100 B4000008 JAL #110Ch
  110C D43F0000 LDW R1, R31, #0h
  1110 B8010018 BEQZ R1, #112Ch
  112C 6FBDFFFC SUBI R29, R29, #FFFCh
  1130 C3800000 LHI R28, R0, #0h
  1134 679C1160 ADDI R28, R28, #1160h
  1138 C0200000 LHI R1, R0, #0h
  113C 64211040 ADDI R1, R1, #1040h
  1140 D4210000 LDW R1, R1, #0h
  1144 6FBD0004 SUBI R29, R29, #4h
  1148 E03D0000 SDW R1, R29, #0h
  114C B4000004 JAL #1154h
  1154 D43F0000 LDW R1, R31, #0h
  1158 B8010004 BEQZ R1, #1160h
  1160 67BD0004 ADDI R29, R29, #4h
  1164 B3FFFEB0 J #1018h
  1018 B0000040 J #105Ch
  105C BC00FFFC BNEZ R0, #105Ch
  1060 BC01FFFC BNEZ R1, #1060h
  1064 BC02FFFC BNEZ R2, #1064h
  1068 BC03FFFC BNEZ R3, #1068h
  106C BC04FFFC BNEZ R4, #106Ch
  1070 BC05FFFC BNEZ R5, #1070h
  1074 BC06FFFC BNEZ R6, #1074h
  1078 BC07FFFC BNEZ R7, #1078h
  107C BC08FFFC BNEZ R8, #107Ch
  1080 BC09FFFC BNEZ R9, #1080h
  1084 BC0AFFFC BNEZ R10, #1084h
  1088 BC0BFFFC BNEZ R11, #1088h
  108C BC0CFFFC BNEZ R12, #108Ch
  1090 BC0DFFFC BNEZ R13, #1090h
  1094 BC0EFFFC BNEZ R14, #1094h
  1098 BC0FFFFC BNEZ R15, #1098h
  109C BC10FFFC BNEZ R16, #109Ch
  10A0 BC11FFFC BNEZ R17, #10A0h
  10A4 BC12FFFC BNEZ R18, #10A4h
  10A8 BC13FFFC BNEZ R19, #10A8h
  10AC BC14FFFC BNEZ R20, #10ACh
  10B0 BC15FFFC BNEZ R21, #10B0h
  10B4 BC16FFFC BNEZ R22, #10B4h
  10B8 BC17FFFC BNEZ R23, #10B8h
  10BC BC18FFFC BNEZ R24, #10BCh
  10C0 BC19FFFC BNEZ R25, #10C0h
  10C4 BC1AFFFC BNEZ R26, #10C4h
  10C8 BC1BFFFC BNEZ R27, #10C8h
  10CC BC1CFFFC BNEZ R28, #10CCh
  10CC BC1CFFFC BNEZ R28, #10CCh
  10CC BC1CFFFC BNEZ R28, #10CCh

And now the code (and someone has to laugh this time!)
*edited* code removed, as its not the latest version. I don't have the latest version for download right now, but will release it instantly, if someone asks.

And here is the trace with register dump:
out.txt

You can very easily change the .c file to act as a non interactive debugger.

Thats it for today from me.

Originally Posted by Disabled

I can run your dump and the machine shows the same trace as in post #25. That doesn't mean much, as there are no conditional jumps (after I calculate something) in that trace and on the first conditional jump after a calculation it goes in an infinitive loop.

Ok i will post a longer trace soon. The infinite loop suggests that the emulator did something wrong

Btw. you missed something i explained in posting #22: The 00000.svm file has a 18h byte long header so when i say the execution starts at 0x1000 this translates to address 0x1000+0x18=0x1018 in the file.

Originally Posted by Disabled

Thats it for today from me.

Looks good. Thank you.

[Disabled]

Originally Posted by Oopho2ei

Btw. you missed something i explained in posting #22: The 00000.svm file has a 18h byte long header ...

Yeah I really missed that but it didn't matter anyway, as 24 is mod 4 and there were just nops. But I corrected that.

A longer trace would be greatly apreciated. I try to evaluate the asm myself, but I don't find an error.

[Disabled]

One important question (and thus I'm not editing the post above):
Is the programm loaded to memory bevor execution? IE is the mem of the VM initialized with zeros, or is one section copied to memory before execution?
That would give the trace at least a bit of sense - but doesn't change anything, it loops on the same way. I'm trying to find a bug in the sdw cmd now (as thats one I added to bmnots code).

*edit* I think with some more hacks to the code I got it to execute a little longer. I indeed loaded one code section to memory and executed from there. Now it segfaults due to a jump to 0x8000000... Here is the new trace:

      1000 B0000040 J #1044h
      1044 BC00FFFC BNEZ R0, #1044h
      1048 BC01FFFC BNEZ R1, #1048h
      104C BC02FFFC BNEZ R2, #104Ch
      1050 BC03FFFC BNEZ R3, #1050h
      1054 BC04FFFC BNEZ R4, #1054h
      1058 BC05FFFC BNEZ R5, #1058h
      105C BC06FFFC BNEZ R6, #105Ch
      1060 BC07FFFC BNEZ R7, #1060h
      1064 BC08FFFC BNEZ R8, #1064h
      1068 BC09FFFC BNEZ R9, #1068h
      106C BC0AFFFC BNEZ R10, #106Ch
      1070 BC0BFFFC BNEZ R11, #1070h
      1074 BC0CFFFC BNEZ R12, #1074h
      1078 BC0DFFFC BNEZ R13, #1078h
      107C BC0EFFFC BNEZ R14, #107Ch
      1080 BC0FFFFC BNEZ R15, #1080h
      1084 BC10FFFC BNEZ R16, #1084h
      1088 BC11FFFC BNEZ R17, #1088h
      108C BC12FFFC BNEZ R18, #108Ch
      1090 BC13FFFC BNEZ R19, #1090h
      1094 BC14FFFC BNEZ R20, #1094h
      1098 BC15FFFC BNEZ R21, #1098h
      109C BC16FFFC BNEZ R22, #109Ch
      10A0 BC17FFFC BNEZ R23, #10A0h
      10A4 BC18FFFC BNEZ R24, #10A4h
      10A8 BC19FFFC BNEZ R25, #10A8h
      10AC BC1AFFFC BNEZ R26, #10ACh
      10B0 BC1BFFFC BNEZ R27, #10B0h
      10B4 BC1CFFFC BNEZ R28, #10B4h
      10B8 BC1DFFFC BNEZ R29, #10B8h
      10BC BC1EFFFC BNEZ R30, #10BCh
      10C0 BC1FFFFC BNEZ R31, #10C0h
      10C4 C3A00000 LHI R29, #0h
      10C8 67BD115C ADDI R29, R29, #115Ch
R29:115C, 
      10CC C3800000 LHI R28, #0h
R29:115C, 
      10D0 679C1000 ADDI R28, R28, #1000h
R28:1000, R29:115C, 
      10D4 D7BD0000 LDW R29, R29, #0h
R28:1000, R29:6FBD001C, 
      10D8 E3BC0000 SDW R29, R28, #0h
R28:1000, R29:6FBD001C, 
      10DC D7A10000 LDW R29, R1, #0h
R28:1000, R29:B3FFFFFC, 
      10E0 C3A0001F LHI R29, #1Fh
R28:1000, R29:1F0000, 
      10E4 67BDFFFC ADDI R29, R29, #FFFCh
R28:1000, R29:1FFFFC, 
      10E8 B4000008 JAL #10F4h
R28:1000, R29:1FFFFC, R31:10EC, 
      10F4 D43F0000 LDW R1, R31, #0h
R28:1000, R29:1FFFFC, R31:10EC, 
      10F8 B8010018 BEQZ R1, #1114h
R28:1000, R29:1FFFFC, R31:10EC, 
      1114 6FBDFFFC SUBI R29, R29, #FFFCh
R28:1000, R29:1F0000, R31:10EC, 
      1118 C3800000 LHI R28, #0h
R29:1F0000, R31:10EC, 
      111C 679C1160 ADDI R28, R28, #1160h
R28:1160, R29:1F0000, R31:10EC, 
      1120 C0200000 LHI R1, #0h
R28:1160, R29:1F0000, R31:10EC, 
      1124 64211040 ADDI R1, R1, #1040h
R1:1040, R28:1160, R29:1F0000, R31:10EC, 
      1128 D4210000 LDW R1, R1, #0h
R28:1160, R29:1F0000, R31:10EC, 
      112C 6FBD0004 SUBI R29, R29, #4h
R28:1160, R29:1EFFFC, R31:10EC, 
      1130 E03D0000 SDW R1, R29, #0h
R28:1160, R29:1EFFFC, R31:10EC, 
      1134 B4000004 JAL #113Ch
R28:1160, R29:1EFFFC, R31:1138, 
      113C D43F0000 LDW R1, R31, #0h
R1:1F3E8, R28:1160, R29:1EFFFC, R31:1138, 
      1140 B8010004 BEQZ R1, #1148h
R1:1F3E8, R28:1160, R29:1EFFFC, R31:1138, 
      1144 5C010000 JALR R1
R1:1F3E8, R28:1160, R29:1EFFFC, R31:1148, 
     1F3E8 6FBD0010 SUBI R29, R29, #10h
R1:1F3E8, R28:1160, R29:1EFFEC, R31:1148, 
     1F3EC E3DD000C SDW R30, R29, #Ch
R1:1F3E8, R28:1160, R29:1EFFEC, R31:1148, 
     1F3F0 67DD0010 ADDI R30, R29, #10h
R1:1F3E8, R28:1160, R29:1EFFEC, R30:1EFFFC, R31:1148, 
     1F3F4 E3FEFFF8 SDW R31, R30, #FFF8h
R1:1F3E8, R28:1160, R29:1EFFEC, R30:1EFFFC, R31:1148, 
     1F3F8 E05D0000 SDW R2, R29, #0h
R1:1F3E8, R28:1160, R29:1EFFEC, R30:1EFFFC, R31:1148, 
     1F3FC E07D0004 SDW R3, R29, #4h
R1:1F3E8, R28:1160, R29:1EFFEC, R30:1EFFFC, R31:1148, 
     1F400 D47E0000 LDW R3, R30, #0h
R1:1F3E8, R28:1160, R29:1EFFEC, R30:1EFFFC, R31:1148, 
     1F404 B4001874 JAL #20C7Ch
R1:1F3E8, R28:1160, R29:1EFFEC, R30:1EFFFC, R31:1F408, 
     20C7C 6FBD0010 SUBI R29, R29, #10h
R1:1F3E8, R28:1160, R29:1EFFDC, R30:1EFFFC, R31:1F408, 
     20C80 E3DD000C SDW R30, R29, #Ch
R1:1F3E8, R28:1160, R29:1EFFDC, R30:1EFFFC, R31:1F408, 
     20C84 67DD0010 ADDI R30, R29, #10h
R1:1F3E8, R28:1160, R29:1EFFDC, R30:1EFFEC, R31:1F408, 
     20C88 E3FEFFF8 SDW R31, R30, #FFF8h
R1:1F3E8, R28:1160, R29:1EFFDC, R30:1EFFEC, R31:1F408, 
     20C8C E05D0000 SDW R2, R29, #0h
R1:1F3E8, R28:1160, R29:1EFFDC, R30:1EFFEC, R31:1F408, 
     20C90 C0200000 LHI R1, #0h
R28:1160, R29:1EFFDC, R30:1EFFEC, R31:1F408, 
     20C94 64211150 ADDI R1, R1, #1150h
R1:1150, R28:1160, R29:1EFFDC, R30:1EFFEC, R31:1F408, 
     20C98 C0400002 LHI R2, #2h
R1:1150, R2:20000, R28:1160, R29:1EFFDC, R30:1EFFEC, R31:1F408, 
     20C9C 6442047C ADDI R2, R2, #47Ch
R1:1150, R2:2047C, R28:1160, R29:1EFFDC, R30:1EFFEC, R31:1F408, 
     20CA0 E0410000 SDW R2, R1, #0h
R1:1150, R2:2047C, R28:1160, R29:1EFFDC, R30:1EFFEC, R31:1F408, 
     20CA4 E0410004 SDW R2, R1, #4h
R1:1150, R2:2047C, R28:1160, R29:1EFFDC, R30:1EFFEC, R31:1F408, 
     20CA8 60420400 ADDIE R2, R2, #400h
R1:1150, R2:2087C, R28:1160, R29:1EFFDC, R30:1EFFEC, R31:1F408, 
     20CAC E0410008 SDW R2, R1, #8h
R1:1150, R2:2087C, R28:1160, R29:1EFFDC, R30:1EFFEC, R31:1F408, 
     20CB0 D45D0000 LDW R2, R29, #0h
R1:1150, R28:1160, R29:1EFFDC, R30:1EFFEC, R31:1F408, 
     20CB4 D7FEFFF8 LDW R31, R30, #FFF8h
R1:1150, R28:1160, R29:1EFFDC, R30:1EFFEC, R31:8000000, 
     20CB8  7A0F000 ADD R29, R0, R30
R1:1150, R28:1160, R29:1EFFEC, R30:1EFFEC, R31:8000000, 
     20CBC D7DEFFFC LDW R30, R30, #FFFCh
R1:1150, R28:1160, R29:1EFFEC, R30:FC000000, R31:8000000, 
     20CC0 581F0000 JR R31

Originally Posted by Disabled

Is the programm loaded to memory bevor execution?

Of course the program is loaded into memory before execution. The program counter is the address of the instruction in the memory. I uploaded a memory snapshot in posting #39. Please have a look at it.

Originally Posted by Disabled

Now it segfaults due to a jump to 0x8000000

As stated prior in posting #24: Before you load the next instruction you adjust the program counter by calculating "PC = PC AND 0x3FFFFC;".

Hope that helps.

I will record the extended trace now. Expect a set of binary files. Each file is associated with exactly one command and contains a list of the results of this command in the order of execution. So to get the result of a particular instruction eg. "ADD Rd,Rs1,Rs2" you would have to open the file "cmd01_trace.bin" and look at address 4*i where i is the number of times this command (add) has already been executed. The 32bit value at this address would be Rd. You would need to write a program which keeps track of how many times every command has been executed. After the execution of every command your program is supposed to compare the result and abort execution once a difference has been found.

Btw. by the term "instruction" i mean "command + parameters". Just to avoid confusion ^

[Disabled]

Originally Posted by Oopho2ei

Of course the program is loaded into memory before execution.

It wasn't in the original post from bmnot and he zeroed the mem first and I didn't find what memory I should load into the mem (a 2MB segment, and zero the following 2MB, or just copy 2 segments or what?).

As stated prior in posting #24: Before you load the next instruction you adjust the program counter by calculating "PC = PC AND 0x3FFFFC;".

Hope that helps.

No it does not. It sets the pc to 8000000 and in the next step it does the 0x3ffffc. And I also changed the jump directly, it doesn't change anything, as 800000 & 0x3FFFFC = 0 and at that adress is a j 0
*edit* of course I forgot to set pc to &0x3ffffc in the next step, but as already written, that does not change anything. */edit*

I will record the extended trace now. Expect a set of binary files. Each file is associated with exactly one command and contains a list of the results of this command in the order of execution. So to get the result of a particular instruction eg. "ADD Rd,Rs1,Rs2" you would have to open the file "cmd01_trace.bin" and look at address 4*i where i is the number of times this command (add) has already been executed. The 32bit value at this address would be Rd. You would need to write a program which keeps track of how many times every command has been executed. After the execution of every command your program is supposed to compare the result and abort execution once a difference has been found.

Uhh that looks like a bit of work. How about just dumping the regs every step and comparing them at each step? And recording the PC too...

Originally Posted by Disabled

It wasn't in the original post from bmnot and he zeroed the mem first and I didn't find what memory I should load into the mem (a 2MB segment, and zero the following 2MB, or just copy 2 segments or what?).

Just load the first section (2MB) at the base (skip the header) and leave the other 2MB free.

Originally Posted by Disabled

No it does not. It sets the pc to 8000000 and in the next step it does the 0x3ffffc. And I also changed the jump directly, it doesn't change anything, as 800000 & 0x3FFFFC = 0 and at that adress is a j 0

*lol* but j #0 would be correct. You see that with all those instructions they test if your interpreter/emulator is working correctly. Just wait for the trace. We will fix those problems.

Originally Posted by Disabled

Uhh that looks like a bit of work. How about just dumping the regs every step and comparing them at each step? And recording the PC too...

This is just easier to to do for me. Also you are not supposed to compare the result of every instruction yourself. Your program can do that for you.

[Disabled]

... leave the over 2MB+0x16 free.... right?

*lol* but j #0 would be correct.

But if I do a j #0 at adress 0, then its an infinite loop... so there has to be an error.

You see that with all those instructions they test if your interpreter/emulator is working correctly.

That took me a long time to understand. The code just didn't made sense until I realized that.

This is just easier to to do for me. Also you are not supposed to compare the result of every instruction yourself. Your program can do that for you.

The question is, who of us both has more time? Opening one file and comparing 33 values would be very easy to code for me, opening 0x3F files, incrementing one of 0x3F counters each step and comparing one value each step sounds a little more complex to me. (I know I can array and loop those duties too.)
On a second thought it doesn't sound too hard to do...

A general note: Doubts have been raised about my statement that the virtual machine is "little endian" in posting #20. I have to admit that i probably made a mistake there and the virtual machine is most likely big endian. Therefor i have edited posting #20.

Please feel free to post your comments if you think i am wrong at any point.

[Disabled]

Ok, I guess I have the debug code written. Now I just need a dump to proove it...

*edit*
And another update to the VM, this time the decoded instructions count has nearly tripled. It works till the 278th instruction and that instruction is a trap. But its trap #10h and not #110 as you indicated and the registers and everything are very different. I have some ideas where the problem might be and will try to solve them. Until then, here is the new trace.

I didn't release the updated source to the vm yet, but will instantly, if someone is interested to participate.

*edit2* I think you are right with it being Big Endian. That was one of the first things I changed after I got the basic concept running, but never realized it might be something to report back - sorry.

[bmnot]

Hi,

I'm glad work on this has progressed. Unfortunately, I'm pretty busy at the moment - job and changing flat - the latter effectively preventing any productive work on this topic. So currently you don't need to worry about collisions regarding coding... feel free to use the code in any way you like.
(maybe we'll need a svn some day).

Anyway, I thought a while about convenient/efficient BD+ debugging...

A graphical debugger for the VM would be interesting - with all the disassembled (or even decompiled?) instructions in a window on the left, register contents/PC/watchdog counter etc. on the right and the possibility to step through the code, set breakpoints etc.

As soon as I find some time (weekend), I'll look over the code and join the experiments with the VM.
If it turns out that this would mean significant progress, I'll implement a graphical debugger... If there are no objections, I'd do this in Java (or is anyone already working on such a debugger?).
There are two options regarding the actual VM:
- implement it in Java, too (easier to compile & debug)
- let the C++-VM provide a JNI interface
Any opinions/preferences/suggestions on this? Personally, I find Java more convenient - just dealing with signed and unsigned values is more annoying (that's why I used C++ initially).

By the way, what's actually the long term goal of the BD+-VM? I'd say, bringing it to a form in which it can be easily integrated into other programs such as KenD00's DumpHD (which is by the way Java, too).

From the patent application:

Players also provide procedure calls to enable content code to load data from media, perform network communications, determine playback environment configurations (225), access secure non-volatile storage, submit data to CODECs for output (250), and/or perform cryptographic operations.

Guess that means we'll have to find and implement some kind of "BD+ API" - with exactly the correct behaviour (so our VM cannot be distinguished from a "real" one).

[Disabled]

Hi Bmnot and glad to hear your voice here.
To be honest, I shouldn't have time for this too, but I'm too lazy to do the work I should do...

A graphicall Debugger would of course be nice. On top of my code it would be pretty easy to attach an gui if I just had any experience with gui-programming. Right now you can use the main class as a non-interactive debugger(*), but the need to recompile the whole project everytime you change something to the debug instructions makes it not so easy to use, but a recompilation is needed anyways most of the time, as I change something to the main codebase way more often.
I don't mind using Java, I did far more in Java than in C++...

My long term goal with the vm is... do something until Oopho2ei tells me to add another thing... Sure if it ever is able to decrypt something it will be integrated into other tools or developed into a standalone app. Right now I have no idea what the next step will be. Fixing bugs for sure, but after that all there is left are the traps are there? (And the watchdog, but as I understand, execution just stops when the watchdog reaches 0, so what if I just ignore the watchdog? Or are there traps that can use the watchdog as input...?)
And traps are what I understand you call the BD+ API, is it?

*edit* I forgot to post the latest bdvm code. I really cleaned it a lot and from my ideas this is not the worst code I've seen anymore.

(*) And I wanted to clear this a little. This is the int main():

int main() {
    ExperimentalBdVM a;  //create BdVM object
	a.loadFile("mem");   //mem is actually a header stripped 2MB extract of 00000.svm
	a.initVM(0x1000);
	//a.loadMem("mem");
	//a.loadRegisters("reg_file.000");
	//a.debugon();
	
	for (int i=0;i<34;i++){
		a.step();
	}
	//a.dumpMem("dump.txt");
	for (int i=0;i<250;i++){
		cout << a.instruction_counter +1<<endl;
		a.step();
		a.dispRegisters();
	}
}

The ExperimentalBdVM object has no main loop. All it can do is taking a step. Of course something setting breakpoints or something could easily be implemented. And for an actual gui debugger some of those functions would have to be adapted but still...